Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

Joseph Edward talks Business Architecture, AI & Communities

Agora Insights International — Tue, 14 May 2024 07:30:00 GMT

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Architecture and AI

In our recent conversation with Joseph Edward, we explored the transformative power of business architecture (BA) and technology as tools for uplifting communities. Joseph, with his rich background spanning from education to IT leadership, shared his unique insights on how technology can serve as a strategic enabler rather than just a back-office tool. His journey from teaching in Sri Lanka to spearheading IT initiatives in Canada offers a wealth of knowledge on the role of BA in driving meaningful change.

Background

Joseph Edward's professional path is marked by a series of pivotal roles that shaped his understanding of business architecture. From his early days as a math teacher to his tenure at the Roman Catholic Diocese of London, ON, Canada where he established the first IT department, Joseph has always viewed technology as a strategic enabler.

Joseph's academic foundation began with a Bachelor of Science degree from the University of Peradeniya in Sri Lanka. His career trajectory took an unconventional route from teaching mathematics to embracing information technology after relocating to Canada, where he completed a Computer Science degree at Concordia University in Montreal.

Joseph's professional story is one of strategic innovation and leadership. He established the first IT department at the Roman Catholic Diocese of London, where he crafted their inaugural IT vision and strategy. His role as the Chief Information Officer for the City of London, Ontario, further honed his skills in aligning technology with business goals. At London Life insurance company, now Great-West Life, he deepened his expertise in BA.

In 2014, Joseph founded Invorg, focusing on aiding small to mid-sized businesses in their digital transformation journeys. His approach is rooted in a belief that technology should serve as a strategic enabler, uplifting communities and enhancing organizational capabilities. Joseph's work exemplifies the transformative power of combining technological insight with a passion for community betterment.

3 Key Topics

1. The Importance of Business Architecture:

Joseph's insights reaffirmed the significance of BA as a strategic imperative for organizations. His conviction that technology should serve as a strategic enabler rather than merely a back-office tool resonated strongly with me. The notion that a comprehensive understanding of an organization's capabilities is foundational to any meaningful digital transformation highlights the indispensable role of BA. It acts as a blueprint, guiding and informing the pathways through which an organization can achieve its goals and objectives. This strategic framework is not just about implementing new technologies; it's about fostering a holistic view that aligns with the organization's mission and vision.

2. Business Architecture with AI:

Looking ahead, Joseph sees BA evolving to incorporate emerging technologies such as artificial intelligence (AI) and machine learning (ML). These tools can enhance the efficiency and comprehensiveness of BA practices, providing deeper insights into organizational capabilities and informing the digital transformation process.

The idea that AI and ML could potentially reduce the time it takes to develop a business' architecture from years to days is a game-changer. It suggests a future where business architects can leverage these tools to gain deeper insights and more efficiently align organizational capabilities with the demands of a rapidly changing digital economy. However, this evolution also implies a need for business architects to continuously develop new skills to effectively harness these advanced technologies.

3. Supporting the Community Through Technology:

Joseph's passion for uplifting communities through innovative digital solutions was particularly inspiring. His company, Invorg, focuses on enhancing the business capabilities of non-profits and local governments, which are often the lifeblood of communities. This approach exemplifies the practical value of business architecture in real-world scenarios. By empowering these organizations to serve their stakeholders more effectively, Joseph demonstrates how technology can be a force for good, aligning with the organization's mission to improve people's lives.

10 Learning Points

Passion is key to becoming a great business architect; without it, success in the field is limited.
Big-picture thinking is essential for business architects to understand and envision the organization's overall framework.
Business architecture must adapt to emerging technologies to stay relevant and effective.
AI and ML can expedite the business architecture process, turning months or years of work into days.
Business architects should develop new skills to leverage AI and ML in their practices effectively.
Digital transformation should start with understanding business capabilities before introducing technology solutions.
The future of business architecture involves not only designing current organizational structures but also anticipating future changes and needs.
Business architects can use AI and ML to gain insights into organizational challenges and their root causes.
Effective business architecture can break down silos within an organization, fostering a more collaborative culture.
Technology should be used to uplift humanity and improve people's lives, aligning with the mission of the organizations it serves.

Close

Joseph Edward's insights provide a compelling narrative on the intersection of business architecture, technology, and community development. His unique perspective underscores the potential for technology to be a strategic enabler when applied with a clear vision and purpose. As we reflect on the conversation, it's evident that the future of technology is not just about the technology itself, but how it can be harnessed to uplift and transform communities, making a lasting positive impact on society.

Chat again next week :)

Youtube Video

More about Joseph Edward

An award-winning visionary leader and IT veteran with a passion for community. I aim to improve communities in everything I do: through my work at INVORG, my charity work, my hiring philosophy, and in the way I interact with people every day. My vision is to uplift communities through technology.

I founded INVORG, a trusted innovation partner helping public service entities transform, in 2014. My vision for the company is to uplift communities through technology. Innovation is at the heart of everything we do.

We specialize in transforming public service entities like government, healthcare, education, and not-for-profits. We help our clients save costs and improve service delivery -- in short, we connect them to whom they serve. We offer CIO as a service, digital transformation strategy, expert-managed IT services, and end-to-end CRM implementation.

Together we will boost employee morale and productivity, increase customer satisfaction, improve organizational accountability and transparency, and streamline internal efficiencies -- resulting in significant annual cost savings.

Uplifting the community is at the heart of everything we do. INVORG develops meaningful opportunities for people who have faced challenges in their career, including unemployed, underemployed, and newcomers's transform your organization together.

To contact Joseph:

Invorg

Munilogic

The AI Business Analyst: With Maria Becerra

Agora Insights International — Tue, 30 Apr 2024 07:41:00 GMT

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - The AI Business Analyst

I recently had an engaging discussion with Maria Becerra, a passionate advocate for AI and an accomplished business analyst, on the AI Business Analyst. Maria is a respected name in strategy, business analysis and AI. Her path from Colombia to Canada and her successful shift into business analysis highlight the importance of adaptability and lifelong learning in our industry. Maria's perspective on the changing role of business analysts in the context of AI is both intriguing and highly pertinent for those aiming to stay competitive in their careers.

In this session, Maria shares her vision of the rise of the AI Business Analyst, the human-in-the-loop, the rate of change in AI, and its implications for how we learn and work. Let's get started...

Background

Maria, with a solid engineering background, found her career bridging the lines of business and technology. Her relocation to Canada was a defining moment as she began to study business analysis at Mohawk College. Her earlier roles in Colombia, while not officially recognized as business analysis, were in fact closely related, showcasing the versatility of her skills. This natural alignment with the Canadian business analysis sector was a key turning point for her.

Maria has always been committed to her professional growth, which is evident from her academic achievements and her active role in the business analysis community. As a leader within the IIBA Hamilton chapter and later as a regional director for Latin America, she has shown an unwavering dedication to the advancement of the field.

Her interest in artificial intelligence and business strategy demonstrates her ability to stay ahead of the curve. Maria emphasises the importance of ongoing education and specialisation, particularly in emerging fields such as artificial intelligence, to ensure that professionals maintain their competitive advantage in the workplace.

3 Key Topics:

1. Volunteering and Career Growth

Maria stressed the importance of volunteering, particularly in her role as President of the IIBA Hamilton chapter. This experience was instrumental in advancing her career, as it equipped her with essential leadership and communication skills and a strong network. She advises newcomers to volunteer not just for community service but as a means for personal and career advancement.

2. AI and Business Analysis

Our discussion brought to light the increasing convergence of AI with business analysis. Maria envisions business analysts taking on the role of AI facilitators, not just users but enablers, with a solid grasp of AI concepts to effectively connect business objectives with technical solutions. She anticipates a future where business analysts will need to specialize in AI to stay relevant, drawing a parallel with the rise of roles such as Salesforce business analysts.

3. Learning and Specialization

Maria recommends a T-shaped learning model for those entering the field: develop a broad set of business analysis skills and then focus on a specialization like AI. She reassures us that despite the fast-evolving nature of AI, the core principles are stable, offering a solid foundation for building expertise without being overwhelmed by constant innovation. It implies that, while the field of AI is rapidly evolving, there is a core body of knowledge on which professionals can focus to develop their skills without becoming overwhelmed by constant change.

As AI continues to permeate various aspects of business operations,
Maria envisions a future where a new breed of business analysts will emerge -
the AI Business Analyst.
"We'll start getting that approach and being the translator
between the business side and the development side,
helping them understand when really to use AI," Maria explained.

10 Learning Points

Formal Education: Structured business analysis training can solidify your understanding and affirm your existing abilities.
Volunteering: Volunteering can be a powerful career catalyst, enhancing both soft and technical skills, as well as expanding your network.
Continuous Learning: Keep your skillset fresh and adaptable by embracing new knowledge and skills. Be patient. Keep exploring. Keep learning. Stay curious. Things will work out.
AI Understanding: Familiarize yourself with the basics of AI to contribute meaningfully to related projects.
T-Shaped Skills: Cultivate a broad knowledge base in business analysis before diving into a specialization such as AI.
Practical Experience: Engaging directly with AI initiatives can enrich your understanding and appreciation for the development process.
Prompt Engineering: Crafting prompts for AI tools requires precision and detail, much like writing clear and thorough requirements.
Human-in-the-Loop: Ensure human oversight in AI data processes for greater accuracy and responsibility.
Misinformation Awareness: Exercise caution with AI-generated content and verify information before acceptance.
Community Engagement: Participate in groups like AI Expedition to stay abreast of the latest developments in AI and business analysis.

Close

The insights and journey of Maria Becerra offer a fresh lens through which to view business analysis and AI. Her advice on volunteering, the necessity of continuous learning, and understanding the role of AI in our field are invaluable for professionals at any stage of their career. By embracing these principles, business analysts can lead the way in technological innovation and become indispensable assets in their organizations.

In conclusion, my dialogue with Maria was not only a window into her professional experiences but also a reflection of the broader shifts and demands in the business analysis landscape. The significance of volunteering for career advancement, the imperative for business analysts to integrate AI into their skillset, and the strategic approach to learning and specialization are key factors that I believe will define the success of business analysis professionals eager to lead and innovate.

Chat again next week:)

"To use AI effectively, you've got to understand the context, the need, the stakeholders."
Deirdre Caren

Feel free to share in our Blueprints for Success Podcast or comment with any questions!

To get weekly videos and interviews from leaders around the world, subscribe to our Blueprints for Success Newsletter on LinkedIn

Interested in business architecture and business analysis certification, corporate and AI training? Go to our website www.agorainsights.com

About Maria

Passionate AI Business Strategist with over 7 years of experience collaborating with diverse teams to drive business growth through data and tech-driven recommendations.

I excel at simplifying complex technical information into practical insights, and with a solid background in business analysis and AI, I can help you navigate the ever-changing world of emerging technologies.

Beyond my corporate role, I enjoy presenting on AI and Business Analysis, and I'm open to opportunities to share my expertise.

I also serve as the Director of AI Expedition, Regional Director of IIBA LATAM, and an ambassador for Women TechMakers. When I am not at work or volunteering, I love to go for a walk, study, travel, and practice yoga (hot yoga!).

If you'd like to connect, please send me a note :)

Talk soon!

Maria Becerra LinkedIn

Academic Theory to Business Analysis with Kingsley Ihejirika

Agora Insights International — Tue, 16 Apr 2024 07:29:00 GMT

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Analysis.

I'm happy to share insights from my recent conversation with Kingsley T. Ihejirika, PhD, an ICT Business Analyst at the Ministry of Justice in New Zealand. Kingsley's unique blend of academic theory and practical expertise sheds light on the path to business analysis, emphasising the importance of continuing to learn and grow rather than relying on past successes.

Youtube Video

Background

Kingsley Ihejirika's background is a tapestry of academia and practical experience. His journey began with a solid academic foundation, having pursued a degree in library and information science. This discipline instilled in him an innate ability to organize thoughts and information, a skill that is invaluable in the field of business analysis. His academic pursuits didn't stop there; driven by a desire to make a global impact and interact with international scholars, Kingsley moved from Nigeria to New Zealand to undertake a PhD in Information Systems at Victoria University of Wellington. His research focused on social media and engagement, particularly how libraries can leverage digital platforms to enhance user engagement and promote readership.

Kingsley's transition from academia to the professional world of business analysis was motivated by his passion for engaging with people and solving real-world problems. Kingsley's approach to business analysis is deeply rooted in his educational background, where he learned to question assumptions, seek context, and apply critical thinking to enable change and deliver value.

3 Key Topics

1. Research and social media:

Kingsley's academic research has had a direct influence on his approach to business analysis. He discussed how theories, such as the Elicitation Likelihood Model (ELM), which he encountered during his PhD, have practical applications in his current role. This connection between theory and practice is a testament to the value of academic research in informing and enhancing professional practice.

Ihejirika's research interests are diverse and include digital resilience, online engagement, and the information behavior of various groups and communities. He has a deep-seated desire to discover and share knowledge, which drives his research endeavors. His work on understanding digital resilience, especially among groups most at risk of digital exclusion, is indicative of his commitment to applying theoretical insights to address societal challenges.

One of his research contributions is the exploration of how migrant communities in New Zealand use social media. This research utilizes social capital theory and the Elaboration Likelihood Model to understand the motivations and behaviors in relation to social media use during different phases of the process. By applying these theoretical models, Kingsley seeks to inform practice and contribute to the development of strategies that can enhance the well-being and integration of communities.

2. Role of Business Analysts:

In our conversation, Kingsley emphasized the role of business analysts as change enablers within an organization. He shared his perspective on the importance of understanding stakeholder needs, recommending solutions that deliver value, and the ability to see beyond immediate challenges to drive long-term organizational change. His insights underscore the multifaceted nature of the business analyst role, which transcends mere requirement gathering and management.

3. Future of Business Analysis:

Kingsley offered his thoughts on the future trajectory of business analysis. He believes that while the profession will continue to evolve with new specializations and branches, the foundational principles will remain consistent. Kingsley's own career aspirations reflect this belief, as he aims to grow into a strategic role, leveraging his skills and knowledge to influence and shape the future of his organization and the broader field of business analysis.

10 Learning Points

Apply Academic Skills: Skills like critical thinking and research developed during academic pursuits can be valuable in business analysis.
Embrace Continuous Learning: The field of business analysis is evolving, and continuous learning is key to staying relevant.
Understand the Problem First: It's crucial to understand the problem thoroughly before looking for solutions.
Remember Context is Key: Always consider the context when analyzing business problems, as it can significantly impact outcomes.
Think of Business Analysis as a Mindset: Approach business analysis with a mindset focused on problem-solving and enabling positive change.
Use AI as an Enabler: AI should enhance human critical thinking, not replace it.
Note that Mentorship Matters: Seek mentors who can guide your professional development in business analysis.
Set Clear Goals: Define what you want to achieve in your business analysis career and work towards those goals.
Understand the Value of Professional Networks: Platforms like LinkedIn are crucial for professional growth and networking.
Don't Rest on Past Successes: Celebrate your achievements but always look forward to new adventures, new challenges and learning opportunities.

Conclusion

Reflecting on my conversation with Kingsley, it's clear that the journey from theory to practice is not just a path but a continuous loop of learning, applying, and teaching. His advice to always question, to understand the context, and to never become complacent with past achievements resonates deeply with our ethos of continuous improvement and growth. So stay curious, embrace learning, and seek out mentors who can guide you along this ever-evolving journey.

Let's continue to build our knowledge and skills together, and remember, whether you're transitioning from academia to industry or looking to climb the ladder within your current field, the principles of critical thinking, problem-solving, and value creation are universal keys to success.

Learn more about Kingsley

With over two years of experience as an ICT Business Analyst at the Ministry of Justice - New Zealand, I apply my data analysis, information governance, and change management skills to deliver valuable outcomes for the organisation and its stakeholders. I enjoy guiding and coaching others, working actively in change initiatives and projects, and providing the right information, requirements, and analysis for effective decision-making and problem-solving.

I am also a passionate educator and researcher, with a PhD in Information Systems from Victoria University of Wellington. My research interests include digital resilience, online engagement, and information behaviour of various groups and communities. I believe in discovering and sharing knowledge that can improve the lives and well-being of people, especially those who are most at risk of digital exclusion or marginalisation. I am a husband, a dad, a writer, a speaker, and a mentor who values collaboration, learning, and growth.

Jigs Jamnadas -Blueprints for Success

Agora Insights International — Wed, 14 Feb 2024 09:53:00 GMT

Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success.

As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struck by his excellent managerial skills and his passion for helping people develop their professional skills and capabilities.

Don’t lose sight of the business problem we are trying to solve.

Background

Jigs is a family man with more than one business analyst in the home! He is well supported by a large community and loves being involved in functions, family, friends, and getting things done. He enjoys running and giving back to the community.

In our conversation, Jigs recounted his journey from a chartered accountant to his current role as Chief Operating Officer. His path highlighted the dynamic nature of business careers and the importance of adapting to new roles and responsibilities. Jigs shared the power of having an unbreakable belief, mastering high-performance habits, and surrounding ourselves with the right people.

Formalize the learning from lived experiences and learn from other people’s lived experiences.

Jigs stressed the significance of continuous learning and development, both formally and informally. He shared insights on how keeping up with new knowledge and fostering critical thinking skills are crucial for business professionals. This included understanding the growing influence of AI and technology and how these could be integrated into business processes.

I am sure you will relate to these key points and the learning points that emerged, all of which are particularly relevant for professionals today.

Key Point 1: Unbreakable Belief

The foundation of success, Jigs says, is having a complete, unquestionable belief in yourself and what you can achieve. If you lack true belief and confidence, you'll constantly second-guess yourself and struggle to take the leap into entrepreneurship or go after your biggest goals. During the tough times on your journey, it's a belief that keeps you pushing forward. Cultivate it early.

Key Point 2: High-Performance Habits

Once you decide what type of success you want and truly believe in, you then need the habits and behaviors in your day-to-day that will get you there. Little, consistent actions compound over the years into incredible results. For Jigs, a few key high-performance habits are: being an extremely early riser to get a head start on the day, committing to outlearn through reading and courses; and carving out time for strategic thinking rather than getting caught up purely in execution. It reminds me of what Aristotle said and I quote: "Excellence is an art won by training and habituation."

Key Point 3: Right People

Who you spend time with shapes who you become. This is so true when it comes to success. Surround yourself with goal-oriented people who have character, who inspire you, and who hold you accountable. Have mentors who are playing the game at a high level. Their mindsets, behaviors, and wisdom will rub off in the best way.

So how do we weave people, their lived experiences, with the intellectual properties that we keep creating with the use of new tools and techniques?

10 Key Takeaways

Be obsessed with serving people at the highest level possible. Success is a byproduct of the value you provide.
Don't major in minor things. Stay focused on your goals and priority activities.
Time block the most strategic parts of your work and life, don't just react to the urgent.
Start before you're ready and push yourself into discomfort. That's where growth happens.
Mindset changes everything. Catch and flip negative self-talk into empowering talk.
Progress compounds over time through consistency. Small daily wins always add up.
Ask for help when you need it. Vulnerability is not a weakness; it's a way to learn.
Recovery is key. To sustain peak performance, master your energy across the body, emotions, and focus.
Have gratitude for exactly where you are while also visualizing your future.
Make decisions fast, and course-correct often. Analysis paralysis kills momentum.

Conclusion

The interview with Jigs was insightful and reminded me of the value of adaptability and foresight in business. When I consider the integration of AI, the value of continuous learning, and the importance of core skills, it's clear that the future of business analysis and architecture is both promising and challenging. It's a field that necessitates a savvy and intelligent approach, which Jigs demonstrates through his work and leadership at Mosaic.

As a parent and a business professional, I believe these conversations are critical for guiding the next generation. It is about providing them with the tools and mindset required to navigate a business environment that is both intelligent and constantly changing. Jigs' insights are not only relevant for today's professionals but also valuable lessons for future leaders.

Advice to my younger self: Must read not only that which will enhance what I currently do but that which I need for the future me.

Feel free to share what resonated in our Blueprints for Success Podcast or comment with any questions!

Interested in business architecture and business analysis certification and corporate training? Go to our website www.agorainsights.com

Blueprints for Success: Episode 3 with Wolfgang Goebl

Agora Insights International — Tue, 13 Feb 2024 12:05:00 GMT

I recently had the pleasure of chatting with Wolfgang Goebl, a visionary in the field of business architecture and enterprise design. His unique approach, which he refers to as "architectural thinking," and his work with the EDGY framework, offer valuable insights into the future of organizational structure and design. This tool covers the essential activities needed to create better enterprises: clarifying and exploring challenges, understanding the current configuration of enterprise elements, and collaboratively charting potential futures.

"To become whole, enterprises must embrace a holistic, collaborative way of design. Transcending silos, combining perspectives, looking for connections instead of divisions. An enterprise designed together works better together." Bard Papegaaij, Wolfgang Goebl and Milan Guenther, curators of EDGY 23.

Background

Wolfgang's journey began with a deep dive into computer science, followed by positions as a project manager, business analyst, and, eventually, enterprise architect. His experience taught him that true enterprise architecture occurs outside of IT departments. This epiphany inspired him to co-found the Intersection Group and collaborate on the EDGY Framework.

Wolfgang's journey from IT to business architecture to a broader enterprise perspective highlights the value of adaptability in one's career. He emphasises the importance of architectural thinking being accessible to business leaders and decision-makers rather than just IT departments. This shift in thought is critical for organisations that want to remain relevant and agile in a climate of rapid change.

Three Key Learning Points:

Key Point 1: Architectural Thinking and Simplification

Wolfgang emphasized the importance of simplifying architectural models to make them more understandable for business professionals. He believes that by reducing complex meta models and creating easy-to-apply tools, businesses can better align their IT and business strategies. This approach not only fosters collaboration between departments but also helps in making more informed decisions that drive the company forward.

Key Point 2: Embracing Change

Throughout the conversation, Wolfgang stressed the need for businesses to be adaptable and responsive to change. He pointed out that many organizations struggle with data quality and system consolidation, which hinders their ability to leverage new technologies like AI effectively. By adopting a clear architectural framework and being willing to rearchitect when necessary, businesses can stay ahead of the curve and unlock their full potential.

Key Point 3: The EDGY Framework

Wolfgang introduced the EDGY framework, which provides a visual and structured way to look at enterprises. It consists of three facets—architecture, experience, and identity—that, when combined, offer a comprehensive view of an organization. This framework allows for a more holistic approach to enterprise design, considering the ambition and journey of the people involved.

10 Key Takeaways

Simplify complex architectural models for better business integration.
Foster collaboration across departments with accessible tools and language.
Focus on outcomes, activities, and objects for a comprehensive enterprise view.
Use visual frameworks like EDGY to facilitate understanding and design.
Recognize the importance of aligning IT strategies with business goals.
Be adaptable and ready to rearchitect systems to leverage new technologies.
Understand that data quality is crucial for the successful application of AI.
Enterprise design is not just about architecture; it encompasses identity and experience as well.
Facilitation and coaching are key roles for architects in helping businesses navigate change.
Encourage community involvement and feedback to continuously improve enterprise design frameworks.

Conclusion

Reflecting on my conversation with Wolfgang, it is clear that his interest in architectural thinking and enterprise design has the potential to transform how businesses approach their structures and strategies. Wolfgang's work with EDGY provides a valuable toolkit for organisations looking to navigate the ever-changing business landscape by breaking down complex concepts and promoting a language that crosses departmental boundaries. His insights are not limited to the tools themselves, but also to the value they provide in terms of creating adaptable, well-understood, and purpose-driven businesses.

Remember, it's not just about the architecture; it's about the people's journeys and shared goals. Keep this in mind as you design and plan the future of your own organisation.

“If you find the right context with a shared ambition and behavioural integrity, magical change can happen in organizations."

Interested in business architecture and business analysis certification and corporate training? Go to our website www.agorainsights.com

Blueprints for Success: Episode 2 with Roger Burlton

Agora Insights International — Tue, 06 Feb 2024 16:19:00 GMT

Our next speaker in our Blueprints for Success series is none other than Roger Burlton, a prominent leader in business architecture. As founder of Process Renewal Group, Roger has spent over three decades helping businesses worldwide translate strategy into execution.

“Intention is everything.” – Roger Burlton

Known for his emphasis on practical application, Roger has developed widely adopted frameworks and techniques, including the Business Process Manifesto - a guide to effective process management. He has also authored seminal books like "Business Process Management: Profiting from Process" and most recently, "Business Architecture - Collecting, Connecting and Correcting the Dots."

Through his consulting, writing, and speaking, Roger actively champions business architecture's power to align strategies, operations, and technology. His approach bridges the common gap between strategy and implementation.

It's a journey...

The way Roger thinks about business architecture is just as deep as his love of marathon running. His professional journey and his personal accomplishments of finishing major marathons around the world, show how dedicated he is to excellence and always becoming better. In this blog post, I look at the main points of our conversation in three main areas and ten learning points that sum up what Roger said.

3 Key Points

1. Intention in Work and Life

Roger emphasizes the importance of intention in everything we do. Whether it's running a marathon or crafting a business model, understanding the 'why' behind our actions is crucial. This principle is not only a professional guideline but also a personal mantra that has driven him to pursue and achieve his marathon goals.

2. The Evolution of Business Architecture

Roger's journey from industrial engineering to process improvement and eventually to business architecture showcases the natural progression of his career as he sought to connect individual improvements to a larger purpose. His approach to architecture in understanding the context and fit of processes within an organization offers valuable lessons in strategic thinking.

3. The Future of Business Architecture

Looking ahead, Roger sees the integration of business architecture with IT implementation as a key trend. He predicts that the industry will move towards tangible results from architectural efforts, rather than treating architecture as an isolated discipline. His optimism about the role of AI, in both aiding architects and offering innovative business solutions, also points to a future where technology and strategic thinking are deeply intertwined.

10 Learning Points

Always start with the question of why you're doing what you're doing.
Intention is everything – it guides the purpose and use of your work.
The journey through business architecture is a natural evolution that responds to the changing needs of people and industries.
Connecting the dots is essential – it's about understanding how different elements work together to achieve a bigger picture.
Flexibility and reusability in business processes are critical and require intentional design.
Stakeholder maps and semantic models are key tools for clarity and avoiding miscommunication.
Architecture should be seen as a way of life, an ongoing process rather than a one-time project.
Education in architecture is crucial, but so is the experience and the ability to apply theoretical knowledge in practice.
The future of business architecture lies in its ability to quickly deliver value and integrate with IT processes.
AI will play a significant role in business architecture, both as a tool for architects and as a component of innovative business solutions.

In Conclusion

Roger's insights are checkpoints along the way, guiding us to a finish line that is not the end, but rather a milestone in the never-ending journey of learning and improvement. Roger's professional journey, like his marathon achievements, exemplifies the power of intention, evolution, and foresight in the field of business architecture.

Interested in business architecture and business analysis certification and corporate training? Go to our website www.agorainsights.com

6 Differences Between Data Exploration and Data Presentation

Zach Gemignani — Wed, 16 Mar 2022 18:55:00 GMT

There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms:

Data exploration means the deep-dive analysis of data in search of new insights.
Data presentation means the delivery of data insights to an audience in a form that makes clear the implications.

Your toolbox for data exploration tools is flush with technology solutions such as Tableau, PowerBI, Looker, and Qlik. "Visual analytics" tools give analysts a super-powered version of Excel for dicing data to facilitate the search for valuable insights. Flexibility and breadth of features is critical; the user needs to handle lots of data sources and doesn’t know in which direction she will go with the analysis.

Data presentation is a different class of problem with distinct use cases, goals, and audience needs. Think about the incredible data stories delivered by the The Upshot, Fivethirtyeight, and Bloomberg. These data journalists often demonstrate data presentation at its finest, complete with guided storytelling, compelling visuals, and thoughtful text descriptions. When compared to these examples, it becomes obvious that the best efforts by a data exploration tool cannot deliver high-quality data presentation.

You need a specialized solution if you really want to communicate data in ways that engage your audience. To understand the differences between data exploration and data presentation tools, let me offer six key ways that the activities are fundamentally different.

1. Audience — Who is the data for?

For data exploration, the primary audience is the data analyst herself. She is the person who is both manipulating the data and seeing the results. She needs to work with tight feedback cycles of defining hypotheses, analyzing data, and visualizing results.

For data presentation, the audience is a separate group of end-users, not the author of the analysis. These end-users are often non-analytical, they are on the front-lines of business decision-making, and may difficulty connecting the dots between an analysis and the implications for their job.

2. Message — What do you want to say?

Data exploration is about the journey to find a message in your data. The analyst is trying to put together the pieces of a puzzle.

Data presentation is about sharing the solved puzzle with people who can take action on the insights. Authors of data presentations need to guide an audience through the content with a purpose and point of view.

3. Explanation — What does the data mean?

For the analysts using data exploration tools, the meaning of their analysis can be self-evident. A 1% jump in your conversion metric may represent a big change that changes your marketing tactics. The important challenge for the analysts is to answer why is this happening.

Data presentations carry a heavier burden in explaining the results of analysis. When the audience isn’t as familiar with the data, the data presentation author needs to start with more basic descriptions and context. How do we measure the conversion metric? Is a 1% change a big deal or not? What is the business impact of this change?

4. Visualizations — How do I show the data?

The visualizations for data exploration need to be easy to create and may often show multiple dimensions to unearth complex patterns.

For data presentation, it is important that visualizations be simple and intuitive. The audience doesn’t have the patience to decipher the meaning of a chart. I used to love presenting data in treemaps but found that as a visualization it could seldom stand-alone without a two-minute tutorial to teach new users how to read the content.

5. Goal — What should I do about the insights?

The goal of data exploration is often to ask a better question. The process of finding better questions gets to new insights and a better understanding of how your business works.

Data presentations are about guiding decision-makers to make smarter choices. Much of the learning (through data exploration) should be done, leaving the equally difficult task of communicating the insights and the actions that should result.

In all these ways, data exploration and data presentation are different beasts. This is why we’ve chosen to focus on building the best possible data presentation tool, Juicebox.

6. Interactions — How are data insights created and shared?

Data exploration can be a lonely endeavor: Analysts work on their own to gather data, connect data across silos, and dig into the data to find insights. Data exploration is often a solitary activity that only connects with other people when insights are found and need to be shared. That is, when…

Data presentation is a collaborative, social activity. The value emerges when insights found in data are shared with people who understand the context of the business. The dialogue that emerges is the point, not a failure of the analysis.

Finding the Middle Ground: Data Storytelling

There is something between the extreme ends of data exploration and data presentation. We believe data storytelling lies in this intersection. Data stories aren’t entirely about “telling”, nor are they in the wilderness of “finding”. It is the opportunity to explain the data in a guided, narrative way where message meets exploration.

While there are tools for exploration (e.g. Tableau) and tools for presentation (e.g. PowerPoint), it is only recently that you’ve had the change to bring both together in one solution.

Zach Gemignani (zach.gemignani@juiceanalytics.com)

CEO, co-founder, author at Juice Analytics

www.juiceanalytics.com

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

CEO and 160 employees skydive to launch a new corporate name in the sky!

BPM_online — Wed, 16 Oct 2019 16:06:00 GMT

Bpm'online, a global business software company leading in the space of low-code, process automation, and CRM, will be soon announcing their new company name. The new name will be launched in the sky via a breathtaking skydiving performance involving 160 bpm’online employees, including the CEO. The new name of bpm’online is to be formally announced on October 30th of this year during their renaming event, with the spectacular skydiving stunt, which highlights the importance and enthusiasm the company devotes to this occasion

Bpm’online is holding a large renaming event on October 30th. Registration for the event is open to anyone interested, and can be attended online. The renaming celebration event will display the launching of bpm’online’s new name in the sky with captivating skydiving footage.

“We wanted our renaming announcement to be truly one of a kind. While brainstorming for a creative way to reveal our new name, we came up with the idea of launching it in the sky. The whole team loved the idea so much that we accepted it immediately,” CEO and managing partner at bpm’online, Katherine Kostereva states. “We were expecting a couple of employees to want to skydive, but were happily surprised to find out that over 160 of our own staff were eager to participate. I was so inspired that I joined in too!”

Over 160 bpm’online employees from multiple countries volunteered to help launch the name by jumping out of a plane and taking the new name into the sky with them. For the majority of the team, including the CEO, this is their first skydiving experience ever. Professional skydivers will join them for the big day, while the rest of the company is enthusiastic to celebrate.

Business Architecture in an Agile World – the What and the How.

EA Learning — Thu, 04 Jan 2018 22:29:00 GMT

My current, favourite question for Executives and Architects is “How do you see Architecture operating in an Agile environment.” This question usually elicits a wry smile and a response along the lines of “I will need to get back to you on that!” Many people are wondering how Architecture will fair in the world of Agile. My answer is I believe very well!

Originally developed to deliver improved outcomes in software development, Agile was the hot management trend for 2017. There are a number of drivers behind this trend, but fundamentally executive teams are looking at new ways to deliver business outcomes and to create value in an environment of increasing complexity and disruption. They see Agile as a way of shaking up old paradigms by empowering their people to be more accountable for delivering outcomes and less constrained by traditional management frameworks and practices.

The principles of Agile are very straightforward. Agile methodologies focus on the following:

Individuals and Interactions rather than processes and tools

Working Solutions rather than comprehensive documentation and project plans

Customer collaboration rather than contract negotiation; and

Responding to change rather than following a plan.

For executives who are operating traditional bricks and mortar business and are seeing their core markets being picked off by smaller and more nimble competitors, this is heady stuff. Agile promises a way to breakdown intractable bureaucracies and take on the new-comers at their own game. However, many organisations have learnt Agile won’t deliver the outcomes that executives want on its own. There needs to be something that focuses all of the creativity and energy engendered by the Agile way of working so that demonstrable business outcomes can be achieved. That something is Business Architecture.

For organisations there are three key questions that need to be answered. Why do we exist, What do we need to achieve and How will we do it! Most organisations are clear on the Why question which is usually articulated in their Mission and Vision statements. Most often this is determined by the board and/ or executive teams and communicated to management who then have to figure what they need to achieve to deliver and how are they going to do it.

I see Agile and Business Architecture as the perfect combination to answer these questions. Business Architecture answers the What needs to be done question while Agile provides an approach as to How outcomes will be delivered.

Business Architecture defines the business model, value streams, capabilities and initiatives (projects) required to deliver strategic outcomes, while Agile leverages the creativity of staff, and the ecosystem in which the organisation operates to find more innovative and efficient ways to deliver strategic outcomes.

Business Architecture takes an organisations strategic intent and defines not only what goals/ objectives need to be achieved but what needs to be done to achieve them. It provides a reference framework in which Agile approaches can operate and ensures that the outputs from the Agile processes are contributing to the organisations strategic goals.

So as Business Architects why do we need to care about, and understand, Agile. The reason is that no matter what our functional expertise, our core purpose is to deliver outcomes for the organisation. In the current environment Agile is fast becoming the preferred methodology to deliver outcomes.

In a recent CIO article on IT project success rates the author Sharon Florentine cited research from the Project Management Institute (PMI) that showed that success rates for IT projects are finally on the rise. The interesting insight as to why success rates are increasing is that organisations are measuring project success in what the author describes as a more mature manner. That is rather than looking at measures such as was the project delivered on time and on budget, they are measuring whether the project delivered the benefits that were required by the organisation. To put it succinctly ‘there is less focus on the means by which a project is deemed successful and more on the end: does the project deliver the business benefits promised?” This has been driven quite significantly by the blurring of the lines between IT and the business with many projects becoming more cross functional and multi-disciplined in their approach, which is fundamentally the Agile way of working.

This is not to say that business benefits weren’t considered as part of the traditional measure of project success but they were usually assessed once the project had closed. If the business environment and/ or needs had changed during the project lifecycle this measure may have become less relevant or in some extreme cases irrelevant. With Agile, organisations are looking at benefits (value in Agile terminology) right from the beginning of the project and they are constantly benchmarking their project outcomes against the required benefits. It all makes intuitive sense, which is why Agile is being embraced by so many organisations, but it does beg the question what are these benefits and where are they defined. In my opinion, this is the core role of the Business Architect.

I mentioned earlier that the reason that executives are embracing Agile is that they want to drive change within organisations so that they can compete and thrive in increasingly fast paced environments. They are committed to this course of action as their professional wellbeing is contingent on achieving this change. This is a golden opportunity for Business Architects to be key drivers of this change by filling the crucial role between strategic intent and Agile execution. It will require Business Architects to question and modify some practices but I see Business Architecture (the What) and Agile (the How) as a valuable combination to drive organisational performance.

Written by Scott Comte, General Manager of EA Learning.

To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.

9 Traits of an Incredible Awesome Leader

Paul Crosby — Wed, 07 Sep 2016 14:34:00 GMT

There are hundreds of traits that make up a good manager, but here are the top 9 skills we recommend for a business analysis leader - or any leader in general.

1. See Design as a Differentiator

Anyone can design but not everyone designs well. Who cares? Frustrated users care. Seeing design as important sets you apart from all other business analysts that don’t’ give it a second thought. Build interfaces that are practical and good looking. Don’t see design as something someone else does – it something you as a business analyst can do.

2. Build the Vision – Be Adaptable to the Approach

Build consensus and a strong vision for the outcome. Share the vision of the outcome for the project far and wide to gain a common understanding within your organization on the vision. Share frequently and share often. Implementing the vision can take a thousand paths. Be adaptable. The way to realize your vision isn’t going to be on a clear cut path – there will be many forks in the road. Understand that planning is important in elicitation of requirements and design, but it’s volatile and subject to frequent changes. Create a planning approach the ensure your path forward is well understood, but balanced against overly complex and detailed planning.

3. Understand Your Customers & Users

At the heart of the vision lays the core user. These are the users that interact with your applications, systems, and processes every day. Without them everything just fades away or collapses. Identify your core users then profile them to build meaningful interfaces and processes targeted directly at them. Target your communications and marketing strategies for your vision and product to them very specifically. Knowing how to turn the heads of your core users and get them to support your vision is critical to your success. Once the core users are on board all the other types of users will fall into place. Build a fan base. Even an accounting application can have a fan base. Fans support you and give you new ideas to build your vision. Treat your fans well and they will support you through thick and thin.

4. Don’t Plan More Than 18 Months Out

Long term planning past 18 months is impossible. Markets and organizations change too rapidly to have road maps or long term planning past 18 months. The second you produce that 5-year plan it’s obsolete. Keep fluid in your planning to reach your vision. You may need to re-group or re-think your approach several times over. It’s better to be aware that you need to change your approach and planning frequently than to forge ahead thinking it will be set in concrete.

5. Plan, Perform, Evaluate, Adjust

We talked about planning above. Here’s a cycle that works:

A. Plan It Out – choose your path to reach your vision. Keep a Requirements Work Plan (RWP). Build the consensus and understanding on the tasks you are performing for the project.

B. Perform the Plan – don’t let the RWP sit idle. Work to carry out the tasks outlined and meet the dates you assigned yourself. This builds trust.

C. Evaluate continuously – be aware your best-laid task list could change in an instant. Be aware of other activities or projects that are pulling you away from meeting your plan. Check your progress against the plan and know when things are going off plan.

D. Re-Plan Proactively – get yourself back on track and re-plan frequently. Keep your team aware of the re-planning process and why re-planning was needed. Frequently re-planning is better than falling too far away from the plan and missing expected dates. There are no hard and fast dates no matter what the project manager tells you.

6. Don’t Rely on One Method of Communication

Email is tried and true but not the only way to communicate out your status, projects success or potential changes to users. Everyone is overloaded with email. Find a new channel of communication to keep your project’s vision and potential organizational impacts visible. Personal notes, open houses where anyone can swing by during a 2-hour period to ask questions, and even hallway meetings are a great way to communicate.

7. Focus on Opportunities – Destroy Problems

Only focusing on problems takes your eye away from opportunities that will bring better results. Choose the bright side and be optimistic in your attitude. New opportunities will present themselves. Be prepared to take advantage of them. Find problems and get to the root cause – then destroy them. Don’t focus on trimming a problem’s branches or cutting it down instead, kill at the roots. Don’t let the problem linger around or give it the ability to grow back.

8. Carefully Build the Team – Build Strong Relationships

If you get the chance to choose team members, then choose carefully. Listen to your gut feeling and don’t bring on board resources that you don’t or can’t trust – even if you can’t explain why. It’s hard to put into words sometimes why you don’t trust. Choosing the right members for the team will make or break the vision. Maintaining a team is equally important. Spend time every week celebrating or gathering the team informally outside of the daily stand-ups or weekly status meetings. Try to hold that meeting somewhere different and fun. Even moving to a different conference room will oddly change the team’s perspective – especially if they are trapped in the same war room every day. Always be grateful and reach out to say “Thank You”. Remember those different communication channels? Don’t always email – try a hand written thank you card or just ask them out for a coffee to say thanks for their help. Building the strong relationships get you through the tough times in a project.

9. Know Your Strengths – Outsource Your Weaknesses

You are not everything to everyone. Figure out your strengths and what you are good at. Personality tests give you a hint but ask around. Listen to what your colleagues, friends, and family believe your strengths are. Play to your strengths – you're strong at certain things for a reason. Know your weaknesses – then outsource them or engage someone to help you overcome them. Ask for help. For extra credit build the project team knowing the strengths and weaknesses of everyone on the team to balance them out.

So here’s the truth. As leaders and contributors in the Business Analysis field, these are the skills we need every day. They are also the skills that founders of companies hold.

Check out more great blogs at Bob the BA today!

Pablo Picasso and Scope Visualization

Paul Crosby — Wed, 07 Sep 2016 14:28:00 GMT

Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reason business expectations about a project are not met, and projects fail.

Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.

Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They lose sight of the project's vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.

So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.

So how do we get everyone on the same page? By that, I mean the same page in the same book!

It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value. Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram. That’s certainly a great tool, and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I presented each server farm as a farm – yup cows and red barn with Farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.

In each barn was an icon that represented a group of servers. There were three groups: leave it alone, upgrade it and consolidate then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.

In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did an excellent job of setting the stage for the project visually. All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a better shared understanding of the project.

The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project. They show the scope of a project outcome.

Building on a good thing, I like to build a context diagram of the current environment at a high level. Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects look at the desire of the stakeholders and sponsors. The desire is stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.

Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Use color to highlight the add, modify or removes based on the context diagram for the current state. Color visually explains where the changes are visualized to occur.

Now you may think I completely lost my mind at this point. Fear not I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible. Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram I will highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.

So when in the project life cycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.

As you move through the project, more and more understanding is acquired. Details need hammering out and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how a change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.

The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information. Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today. Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.

8 Ways to Be a Badass Business Analyst Employee

Paul Crosby — Wed, 07 Sep 2016 14:23:00 GMT

Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.

A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).

This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.

5. Know Thyself Well

Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.

There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.

Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.

Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

How To Effectively Use Observation in Projects

Fareed R — Fri, 20 Mar 2015 05:59:00 GMT

Internships can provide some great learning opportunities. I was lucky enough to learn one of the best lessons on the first day of the very first internship of mine. My mentor at the time asked that, for the first 4 weeks, I invest time in every aspect of his business to learn how everything functions. I thought he was insane yet it was one of the best lessons a college freshman could learn – by observing.

When it comes to projects, Stakeholders usually find it hard to explain what their job is or what the requirements are. So by observing and asking questions one can find out a lot more like the flow and sequence of the activities. Observing can happen passively (by quietly watching) or actively (by engaging with the stakeholder through the entire process).

The best way of capturing the activities, steps and decisions is by using a process flowchart or activity diagrams, also known as lane diagrams. Process modeling is a visual representation or the activities and swim lane diagrams shows these activities and captures the people who perform them. Each person has their own lane so it shows how the work is passed from one person to another.

When my 4 weeks were complete I fully understood how the organizational groups and processes fit into one another. How everything got together and how the products were developed, manufactured, configured and shipped.

Here is what I recently learned through observations in the designing requirement phase of a project.

Firstly define the best conceptual design while staying within the project scope and fulfill the business’ and users’ needs.
Review each step and find out what is working, what they want to keep and what they want to remove or what needs to change.
Start planning once you have all the information.

I am very grateful to my mentor for the internship experience and that, as a professional, I can now understand the value of watching people and processes in action.

More training on: https://www.udemy.com/business-analyst/?couponCode=BusinessAnalystSocialNetwork#/

Every Business Analyst Must Negotiate Like a Pro

Adrian M. — Wed, 11 Feb 2015 00:45:00 GMT

In the larger context of life, it is very clear that negotiation skills are very important and that those that have them are better off than those who don’t.

What about in business analysis? Are negotiation skills important?

The answer is an emphatic: YES! You bet they are!

Business analysts negotiate or facilitate negotiations at every turn. At the very infancy of a project, negotiation skills are used to determine what should be included in the vision of the project, in the project charter.

As details emerge, negotiation skills are used by all parties involved to determine which requests become requirements and which requirements have higher priority.

As the project progresses, negotiation skills are again used to determine the functional design which fulfill the requirements. Technical decisions also require negotiation skills.

While it would be much easier if project decisions were black and white (objective) the reality is that everything is negotiable.

So – if you are a business analyst or systems analyst make sure to add negotiation skills to your repertoire.

Certain individuals are great negotiators from birth, the rest 95% of us need to work on these skills.

We can’t afford not to!

By now you might be wondering if you can do it – if you can be an effective negotiator!

Yes! You can negotiate anything!

Here are some tips and guidelines to help you get started. These are really the notes I jotted down while reading “You Can Negotiate Anything!” a great book by Herb Cohen.

Definitions

Negotiation = activity in which parties are trying to satisfy needs.

Process of Negotiation = It is a way of acting and behaving that can develop understanding, belief, acceptance, respect and trust. It is the manner of your approach, the tone of your voice, the attitude you convey, the methods your use, and the concern you exhibit for the other side’s feelings and needs.

Negotiation Myths

MYTH # 1: We want the same thing therefore if you win I lose
The majority of us think of negotiation as a pie that needs to be divided. Therefore if you get the bigger piece then I get the smaller piece. If I win then you lose. The reality is that needs are not always in opposition: In most negotiating situations, the needs of the two parties are not really in opposition. In a collaborative Win-Win negotiation we are trying to produce an outcome that provides acceptable gain to all parties.

MYTH # 2: Money is the most important thing to the other party
While money is not everything in life, it surely nice to have lots! Deep down each one of us think of negotiation in terms of money. Money seems to be an easy and objective way to keep score and to decide if I negotiated a good deal or not.

The reality is that money is not the only need. If you think most negotiations pivot around money, then you’re mistaken. Money is a need but is only one of many. If you neglect their other needs, satisfying people’s dollar need alone will not make them happy.

MYTH # 3: The other party told me what they want
Most of us assume that the other party will or have already clearly communicated to us their needs and wants. The reality is that the real needs of the other party are often not considered for a number of reasons. Negotiations are never totally about what is being openly talked or contested, be it price, services, products, territory, concessions, money, etc – because negotiators try to conceal real needs or don’t recognize them.

Many folks use negotiations as way of satisfying deeper, often subconscious, needs such the need to be appreciated, wanted, and recognized. What is being discussed, and the manner in which it is being considered, are used to satisfy psychological needs.

Win-Win Negotiations

PRINCIPLE: Negotiate for Mutual Satisfaction (Win-Win)
If there is only one thing that you get out of this article is the importance of having a win-win view of the negotiation process. Successful negotiators view the opposing party as colleague rather then an opponent.

The goal at the end of the day is for the parties to shake hands and say something like “That was fun and mutually benefiting! Hope we get to do this again sometime!”

Therefore, your goal and mindset in any negotiation should be to:

Use the process to meet needs (the other party’s needs)
Harmonize or reconcile needs (yours with the other party’s)
Watch for and avoid conflicts which stem from differences in experience, information, and role.

More tips to achieve win-win outcomes for the business analyst:

Build Trust - Find out as much as you can about the other party needs and wants, show genuine concern for the other party’s welfare, and transform the relationship in to collaboration.
Don’t make enemies – As a business analyst you interact with people possessing various levels of knowledge. If you know more or understand it better don’t forget the power of your attitude – check your own ego at the door.
Communicate your needs – Many of us do not succeed at negotiations because we don’t make our needs known. The squeaky wheel really gets the grease, if it knows where, when and how to squeak.

The bottom line is that as a business analyst or systems analyst, you can’t afford not to learn how to negotiate. Learning to be a good negotiator takes time so start now.

If you don’t plan on making a conscience effort to improve your negotiation skills through practice, reading, courses, etc., then keep this on thing in mind… try to help the other person win, make them successful, they’ll remember you.

Another way to put this is summarized by the golden rule: “treat others as you would like to be treated.”

If you do this you’re well on your way to many successful negotiations.

Adrian

The Case for System Documentation aka "Developer Is No Longer King"

Adrian M. — Wed, 14 Jan 2015 23:01:00 GMT

If you are managing a team of business analysts or systems analyst you probably have two main goals in mind:
- to make sure your team understand the requirements (the real ones)
- to make sure that you develop a solution which makes sense in the context of your constraints.

The chances are that one of your biggest constraints is a current system. Few of us have the luxury of working on developing brand new systems starting with a clean slate.

Most of us need to be able satisfy the new requirements in the context of an existing system. But do you know what the current system does?

Do you know the “AS-IS” of your system?

At the core of the Agile manifesto is the call to value “working software over comprehensive documentation”.

I could not agree more!

After all – what good to anybody is the documentation if the software doesn’t work?

Unfortunately many proponents of Agile development tend to miss the fact that the agile manifesto does not say “no documentation”. Whether this is by mistake or by design, I don’t know.

But I do know that, as a business analyst or system analyst, decent documentation made my life much easier and saved my clients a ton of money.

Let’s assume for a second, that the software does work… and that whoever specified and implement the first version did such a great job that the software satisfies all the initial requirements.

But also assume that there’s not documentation!

Now you are hired as the next business systems analyst and are being tasked to help out with the development of version 2 of the software. You might be able to do a great job gathering the requirements but when it comes to specifying what needs to change about the system – you’re stuck! You don’t know what the system does… Yes – you can play with the current system and try to infer what it does but unfortunately the only documentation is “the code”.

Let’s be honest – the technical landscape is constantly changing and most business analysts (even the technical ones) do not have the time or the inclination to maintain enough development skills so that they would be able to navigate their way through a number of technical layers (databases & stored procedures, middle layers and services, web server code and client side-script, etc.) a variety of languages (SQL, C#, JavaScript, Java, etc.), as well as a mixture of architectural models (Client-server, SOA, n-tier, etc.)

You are now at the mercy of the developers – and hope that some of the ones which developed the first version are still around.

These types of environments are the ones where the developer is King. The analyst finds himself at the mercy of those who can read code and navigate the technical layers.

I am not advocating that, as a business analyst or system analyst, you do not increase your technical skills; I’m just saying that, unless you become a developer, you’ll need some level of system documentation to point you in the right direction.

As a rule of thumb here are a few project characteristics which would indicate that maintaining live system documenting might be advisable:

the project is large (with a large team)

the business domain is very complex

analysis is done on-shore but the development is done off-shore

the system is supposed to be in use for years to come (i.e. there will likely be lots of turnover in staff over the years)

regulatory requirements exist which require certain level of system documentation (at least in the area of security, legal compliance, etc.)

building services or components which will be re-used by other teams (the clients)

I will be the first to admit that maintaining decent (good enough) system documentation is not easy. In large teams and large projects you must have the commitment of the management (the folks with the money) to maintain system specifications.

I have worked on many a project where the initial set of documentation was quite good but as soon as the first “emergency” arose, exception was granted to code without specs which were supposed to be updated “later”. In such cases – “later” usually never comes.

Another must for your organization, if you’re going to maintain system specs, is guidelines and standards. Whatever level you decide to maintain your specs you must create and publish a set of standards for your documentation. This way everybody knows how to read it and how to keep it in synch with the code.

Do you maintain system documentation? Why or why not?

Adrian

Employers Should Do More to Train Business Analysts

Adrian M. — Wed, 17 Dec 2014 12:45:00 GMT

While the Business Systems Analysis line of work is just beginning to be recognized as a profession of its own, the shortage of business analysts and systems analysts continues to get worse.

And the shortage is global!

Would you believe that India is having a shortage of qualified IT professionals? Well, you better believe it!

A while back, Mary Hayes posted a great piece on the shortage of IT talent in India. She stated that “the IT talent shortage there has hit a tipping point.” Four companies alone, Accenture, IBM, Infosys, and Tata were looking to hire additional 35,000 tech workers in India in just the first 6 months.

A separate article, discussing the business analyst shortage in Australia, states that there are simply not enough people to fill the open business analyst positions.

In the USA, the shortage of qualified analysts is just as bad. Just take a look at the sheer number of job postings for business analysts and systems analysts on the major job boards (Dice.com, Monster.com, etc.).

Should universities crank out more graduates?

The reality is that universities can only teach so many technical skills. And most of them do not teach critical competencies need by analysts such as big picture systems thinking, soft skills, problem solving, and requirements elicitation.

I graduated with a degree in Computer Science from UCLA, a school well known for its engineering degrees. However, I had only one course which taught me skills which I had later used as systems analyst. And that course was taught by an outsider, a consultant from RAND corporation. He split the class into small teams and told us to come up with a software product, pitch the idea in front of the entire class, document the requirements, design the system, build it and try to sell it.

Wow! That was cool!

Unfortunately, that was the only such course that UCLA offered and it was just a pilot course which was available for only two quarters (I hope they brought it back).

Most college professors do not have industry experience – they have rarely been involved in developing real systems that customers pay money for.

I am not saying that a technical degree is of no value – I’m just saying that it’s not enough.

So what is the answer?

I believe that employers should do more – much more - to address this problem. Large companies should create in-house training programs to teach real-world skills to future business and systems analysts through a variety of methods: seminars, mentoring, real-life projects, etc.

Many recent tech graduates would be willing to commit to a 2-3 year stay with a major company if they are promised a well-thought out training plan and the prospect that at the end of the training period they would have gained the competencies needed to succeed in the real world as professional business analysts or systems analysts.

Some companies are getting the message!

Infosys, started a program called Campus Connect to polish up the basics and teach vital skills to engineering/computer science students in colleges across India. Yes, they have a great incentive: about 24,000 tech job openings per year.

Kudos to Infosys!!! Everybody benefits!

The Campus Connect program teaches students critical skills such as:
- Systems analysis
- Hardware architecture
- Data storage
- Soft skills
- Problem solving,
- Etc.

Do you think the employers should do more to reverse the shortage trend?

Would love to hear your thoughts!

Adrian

Dealing with Difficult Stakeholders

sbowling999 — Sun, 27 Jul 2014 20:50:00 GMT

The question will undoubtedly arise during your tenure as a business analyst, ‘How do I manage a difficult stakeholder?’

I once encountered a stakeholder, a very highly respected mathematician, who had developed an application based on a mathematical model of his weather systems. The algorithm was amazing. The application sucked. It was my job to:

1. Ensure his model used enterprise data so it could be shared amongst other applications I was helping develop and,

2. To either refactor and debug his application or port his algorithm to a new User Interface so it was available to a larger user group.

Long story short, he hated me. More accurately maybe he hated the idea of me. So what did I do? I elicited his feedback every step of the way. I made him a full partner in the change experience. But I also put my foot down and let him know the change was going to happen. I recognized that he was heavily invested in the application he had grown from scratch. The larger community wasn’t aware of his accomplishment. So I suggested he demo his application to a larger group of users. He got the opportunity to share his vision with the enterprise. People were amazed at the model and he received his just credit and some back slaps. But during the course of the demo he was also slightly embarrassed because there were technical issues and bugs that were apparent (as I knew they would be) which motivated him to embrace the improvement process.

It also helped to understand what was important to him and his own analysis process. Because he was the logical type I crafted my analysis plan to rely more heavily on statistics and fact based decision making. After showing him the error logs for his tool as compared to other applications for example, we agreed together that reducing the instances of error and downtime needed to be our joint #1 priority before we exposed the application to a larger audience. Because I always kept him informed, treated him as my primary stakeholder and never pulled punches, he began to see me more as his partner who could help him through the change process and bring his model to a much larger audience. For that to happen, he had to let go of complete control and we eventually repackaged his model/algorithm into an entirely new UI consistent with our other enterprise applications. Looking back, the only thing I would have done differently is put my foot down on Day 1 instead of Week 3.

It’s also critically important to find out the concerns of your most difficult stakeholder. In another example, I had a difficult stakeholder group who were code enforcement inspectors. You know the guys who condemn houses? As a group they were refusing to use their 2 year old mobile application. Citizen complaints raged as their investigation backlog grew. When their contractor mistakenly demolished the wrong house, the Mayor’s office finally decided to hire me as a consultant to improve their systems and processes. The workers grumbled and pushed back on requests for changes. I decided to select the least tech savvy, most senior vocal influencer and rode with him for a solid week. Every morning at 6 a.m. we met the crew for coffee at McDonalds. I donned work boots and shadowed him as he walked around in dark condemned houses in the worst part of town. We met the guys for lunch at the 7-11, conversed and I truly began to understand their challenges and why they hated the old application. I also understood that the fear of using the technology was elevated due to a general lack of experience with web technology. At the end of the project this ‘difficult stakeholder’ helped me teach the training course and volunteered to be the ‘go to guy’ for all other inspectors! Listening and putting yourself in the stakeholders shoes really works.

So here are my steps to better stakeholder relationships.

Identify key stakeholders who can throw a wrench into your project’s success. Key stakeholders may be members of the executive or management team. They could just as frequently be informal team leaders or members who influence others. Ensure you are proactively nurturing those relationships.
View them and treat them with the importance a key stakeholder deserves. Nothing turns a stakeholder into hostile mode faster than getting a cold reception and the sense that his opinions are not valued.
Take the time to truly understand their perspective and concerns. Put yourself in their shoes. Not only will you be investing in the relationship but you will likely also learn important information that can help craft your analysis, deployment, training or support plans.
Ensure there are ample opportunities for your stakeholders to provide feedback in a setting that is most comfortable to them. Some people aren’t comfortable sharing in a group setting or JAD session.
Be sure to incorporate their feedback into the overall plans so their concerns are addressed.
Recognize that change doesn’t happen overnight. Employ an appropriate change management strategy.
Create opportunities for your difficult stakeholders to show leadership and excellence. Everyone wants to be recognized for their accomplishments.
Engage them to help win the buy-in of other team members who sit on the fence. Nothing ensures your project’s success like having the team leaders champion the change.

The success of a business analyst depends heavily on the relationships he builds along the way. Pay attention to the key stakeholders and remove this obstacle so you can get on with the business at hand.

Oh...I wish I knew this before!

Praveen Udupa — Mon, 23 Dec 2013 13:17:00 GMT

A few years ago, I had shifted with bag and baggage to the US. I thought that the upcoming project would consume me for at least a couple of years. Alas, that was not the case. I returned home in five months. Well, I don't even want to begin to think about the financial and emotional set back that my family and I had to endure!

Why did this happen? The easy answer is always, "Oh! you know, the customer was totally ill-prepared. They did not even have the business case for the project and they had already spent $1M+. Can you believe that? Ultimately the CEO found out that there was no business case and revoked funding." But this was only one of the reasons. There were several others. Among the others, one of the reasons was, well, me! I might have been the reason for the project getting scrapped!

You see, like in every project, there were two critical stakeholder roles for this project - the Sponsor and the Solution Owner. The sponsor was the head of IT. He controlled the budget. The solution owner was a director of a business division and he controlled the solution's features. In most projects, these two roles are played by the same individual. But in this project, these two roles were played by two different individuals.

The PM, the Solution Architect and I were clear - go to the sponsor for budget, estimate approval, release plan and timeline. "Please the sponsor" was our motto. We went to the solution owner only for requirements sign off and kept him out of the loop for discussions on release planning. Here lies the problem!

These two individuals acted based on completely different set of motivations - having just got out of the debacle of a long drawn, several times over budget project, the sponsor wanted to show quick wins by having shorter release cycles, which meant that the budget per release was very limited and thus the features we could accommodate in a release was limited. The solution owner, on the other hand, maintained that each release should be of value to the end users. There is no point in releasing something which the end users would find unexciting. For him, the definition of quick win was not just to make a release, rather to make a release that would win accolades from the end users.

You may imagine what happened next - the sponsor and the solution owner never saw eye-to-eye. That they belonged in two different organizational units and did not have to regularly communicate with each other only exacerbated the situation. I would work with the PM on developing a release plan, estimates and project plan. We would then take it to the sponsor. He would look at it and instruct us to reduce the number of features and hence the estimates. We would do that. He would then approve the release plan. I would then go to the solution owner, who would look at the release plan and literally go ballistic. I would plead helplessness and indicate that I was at the mercy of the sponsor. He would care for none of that.

Eventually, I raised both my hands. I said, you guys work with each other and resolve your differences. Well, I'll tell you something. They did resolve their differences. They had the project scrapped!

Was it my problem that the sponsor and solution owner did not get along? Is there anything that I could have done better? For both questions the answer is a resounding "Most certainly!" If only I had anticipated this tussle between stakeholders! If only I took a more proactive and a hands on approach to diffuse the tension between these two stakeholders. If only, if only...now do you get how I was one of the reasons for the project getting scrapped?

What could I do better? Stakeholder Analysis is a best practice that every BA must have mastery over. Alas, I studied this concept only after I returned from the US feeling like a hapless victim.

The purpose of stakeholder analysis is to analyze the interest and influence of each stakeholder and customize our collaboration strategy with each stakeholder with the sole intention of minimizing the adverse impact on the delivery of the solution. Stakeholder Analysis enables the BA to deal with stakeholders as a matter of choice rather than chance!

So, let's talk about stakeholder management:

Who is a stakeholder?

Stakeholder is anyone who is directly/indirectly, positively/negatively impacted by the problem and/or its solution. It is possible that someone is 'positively' impacted by the problem, in fact they might thrive and flourish inside the problem.

What is Stakeholder Management?

Stakeholder Management is about customizing collaboration strategies to suit the temperament and background of each stakeholder with an intention to "minimize the any adverse impact on the progress of a project" that could caused by a stakeholder.

Step 1: Stakeholder Identification

The first step in Stakeholder Management is obviously identification of all stakeholders. This activity begins as soon as the business needs are identified.

It is important, well, to make sure that all relevant stakeholders' views have been considered in building the solution. The BABOK lists various stakeholder roles that can be used to identify stakeholders. But this is easier said than done. For e.g.

Consider the stakeholder role 'Regulator'. Most of us assume this to be the macro regulatory bodies like SEC, SEBI, FDA, TRAI, IRDA, FSA, etc. But somehow we forget that PMO of an organization is also a regulator - they regulate what, how and when project deliverables need to be produced.
Consider Enterprise Security team. They regulate access to all 'Applications' in the enterprise, including the one that you are defining requirements for. Not only that, they also dictate security related requirements.
Consider Sponsor - the one with the money is the sponsor. We all know that. We assume that the sponsor needs to be pleased all the time. Well, this is not true always. It is not JUST the sponsor that needs pleasing...there are other stakeholders. One of the most critical stakeholders that need to be closely managed is who I call "Business Owner" a.k.a Solution owner. (The BABOK does not call out a separate stakeholder role called solution owner. I assume they include this in their Domain SME.) The Solution Owner decides what features and functionality should the solution provide and also has a say in release planning (i.e. when does which feature become available in the solution. Fair, right?) Normally, there is one individual that sits in the roles of both Sponsor and Solution Owner. This is the best case scenario. The troublesome scenario is when these two roles are played by two different individuals, like in my case (described earlier).

Step 2: Stakeholder Analysis

The second step is stakeholder analysis. This comprises of two parts - understanding a stakeholders 'interest' and understanding a stakeholder 'influence'. Let me dwell on these two points:

1. Stakeholder Interest

It is important to understand stakeholder's interests because it gives us some indication on how much would the stakeholder care about exercising whatever influence s/he might have. Interest is a function of two factors - change appetite of the stakeholder and impact of the solution over the stakeholder.

Change Appetite is the disposition of the stakeholder towards the change. In other words, to what extent is the stakeholder willing to change.
Impact of the solution is to what extent will the solution force the stakeholder to change

Stakeholder Interest is determined as follows:

Change Appetite	Impact of Solution	INTEREST
High	High	HIGH
High	Low	LOW
Low	High	-ve HIGH
Low	Low	LOW

Notice that if the Change Appetite is Low and Impact of Solution is High, the stakeholder will have a NEGATIVE interest in the project, which means that the stakeholder will not hesitate to scuttle the progress of the project or even kill it, provided s/he has adequate influence.

2. Stakeholder Influence

Stakeholder Influence is very simple. It is the degree to which the stakeholder can sway decisions to his/her line of thinking and impact the outcome of the project.

Step 3: Stakeholder Map

The third step in Stakeholder Management is to develop a visual model of stakeholder's interest and influence, which is called a stakeholder map. It looks like this:

Each stakeholder gets assigned a quadrant, with the relative location in the quadrant indicating the extent of influence / interest of the stakeholder compared to other stakeholders. The RED circles indicate the stakeholders who have a negative interest.

"Okay...this is great", I hear you saying. "Now what do I do? What significance do these quadrants hold? What is this about one stakeholder Bob moving from one quadrant to the other?"

A stakeholder map is the four quadrant Interest vs. Influence map. All the stakeholders fall into one of these four quadrants.

What do these quadrants represent?

The I Quadrant (top right) carries the most significance because the stakeholders who are high on both Interest and Influence are bracketed here.

But, mind you, the folk with negative Interest (the RED circles) can appear in the I and IV quadrants only...guess why?

What do I do with this map?

The stakeholder map essentially helps the BA figure out how the collaboration with the stakeholders should be.

I Quadrant - Manage Closely

High Influence & High (Positive) Interest

Work in Collaboration/ Partnership and keep on board.
Manage them closely and maintain support
Refine communications to align with project goals.
Leverage stakeholder influence.
Use in project teams to deliver change.
Reward their support.
Use an interactive communication method - do not use a dictatorial tone with them. Make them feel that every idea is theirs

High Influence & High (Negative) Interest / Resistance

Build Relationships when possible. Take time to know them.
Understand the underlying reasons for resistance. Paint a picture of the future if things continue as is.
Acknowledge their concerns.
Compromise on strategy where it is possible - give and take negotiation
Stand firm on principles and the need for change
Involve other influencing people who are more positive in influencing them
Use an interactive communication method - do not use a dictatorial tone with them. Make them feel that every idea is theirs

II Quadrant - Keep Satisfied
High Influence and Low Interest

Keep them satisfied.
Send regular information about project but not constant involvement.
Ensure that they support the project.
Target communications to align with project goals.
Provide information to help them become supporters
Enthuse about change and sell the benefits.
Use an push communication method.
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence

III Quadrant - Keep Informed
Low Influence and Low Interest

Manage relationship passively - not necessary to seek them out. Be courteous and genuine when they pass by the hallway or in the cafeteria
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
Use a push communication method - no interaction unless asked for.

IV Quadrant - Monitor
Low Influence and High Interest

Consult or have a dialog
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
Empower them and protect their interests
Consider their advice and opinions...no need to bend backwards to accommodate, unless they are really important to the project
Remain in constant communication to ensure that no major issues are arising

Coming back to my situation

So, had I known the above stakeholder management method, rather, had I known its real significance, I would have realized that both my warring stakeholders - sponsor and business owner - fall under the I Quadrant. In hindsight, what could have saved the project is the following collaboration strategies:

Involve both the sponsor and the business owner in all status review meetings (I used to involve only the sponsor)
Facilitate communication between these two stakeholders to ensure that both of them truly understand each other's worlds and both realize that neither is acting with any vested interest, rather, both want the best from the project
Arrive at the Release Plan together, such that both stakeholders' interests are optimally taken care of and that both understand what they are giving up, if at all, and why
Create an atmosphere of trust that neither stakeholder give you any guidance/direction without the knowledge of the other.

Well...better late than never, right? I might have been partially responsible for losing the project, but I did learn a lesson from that.

Let me know what you think...leave a comment!

Want to be an effective professional? Follow up!

Lee Grinberg, CBAP, PMP — Thu, 18 Jul 2013 17:34:00 GMT

Would you like to be perceived as effective? Want to succeed?

Make sure you follow up.

As a BA you are involved in several initiatives at different stages of development. What separates an average professional from an exceptional one is following up on tasks assigned to others on your projects.

I'm too busy, you say? I don't own the tasks, you say?

Well, like it or not the BA has the primary responsibility of making sure requirements are documented, verified, and validated. This involves input from many sources and it's imperative to get the information in a timely manner.

The benefits of following up include:

Your work will be done on time
People will not forget the assigned tasks
You will be perceived as effective

How will I find the time to follow up, you say? Build it into your daily routine.

When sending an email, flag your email for follow up at some later time. Most email programs have this feature.
When speaking with someone, send them an email summarizing the conversation and confirming next steps. Flag the outgoing email as a follow up item.
Most importantly, follow through and follow up when the email reminder comes up.

In Summary, following up will enhance your job by making you effective. Following up is easily done using your email program and having the discipline to act.

Good luck on your assignments!

Do you want stakeholders to trust you?

Lee Grinberg, CBAP, PMP — Mon, 03 Jun 2013 12:23:00 GMT

Do you want to be an effective BA?

The first step is to make the key stakeholders trust you.

As I wrote in my previous post it is the first step in establishing yourself when you're the only BA in your organization.

When I joined and sat down for my first meeting with the project team not only was I met with stares of hostility I was also leveled with questions regarding the need for my role (gasp!) The project sponsor and his right hand who was developing business requirements were feeling threatened and did not want to give up control.

So, how to make them trust you? Develop rapport and give credit!

First, develop professional rapport. Over a few months, I met with them to clearly establish my boundaries (writing functional specs) as opposed to stepping on their turf (business requirements) and to offer my help with clarifications whenever I could. I learned their business terminology and got my hands on as much system information as possible. In the process of developing rapport, I was also learning about the system and became a better BA. This went a long way to establish my earnestness and good intentions.

Second, develop a personal rapport. I got to know these guys pretty well. We had a few drinks, shared personal stories, and trust soon developed. I also asked them for help in navigating the organizational culture. When people help you, they trust you.

The final watershed moment that made them trust me happened in another project meeting. I was doing a presentation on the state of the project to senior management and when the time was right stopped and gave credit to the guys who started it and kept it rolling. I took no credit for myself. This completely established my good intentions.

So, what finally happened? These stakeholders and I have a great working relationship which outlasted the original project.

Are you the first and only one?

Lee Grinberg, CBAP, PMP — Sat, 25 May 2013 11:04:00 GMT

Are you the first and only Business Analyst in your company? If so, you know how hard it is to survive while doing your job and bringing about organizational change. If not, you may be frantically thinking "How do I get out?!".

This post is to share my experience in how to not only survive but thrive!

I joined a mid-size company where there was no Business Analysts or Project Managers. On top of this, the IT team was new with little knowledge of the system. There was an SDLC (sort of) that was being followed but the requirements gathering went something like this:

Business user wants something but he's not so sure what
He pops by the IT department and blurts it out to an unsuspecting developer
Developer codes something the developer is sure the business user wants
QA talks to the business user and developer to figure out what they really want to test (no test plan or testcases)
Go live date and the next few days - chaos as bugs appear and no one quite knows how this happened (again and again)

So by now you're thinking I was marching off to the SVP of the company with a copy of BABOK in hand in a self righteous indignation, right? WRONG.

Open confrontation would only create resentment on the part of the entrenched business and developer community. Instead I laid low for a while, observing taking notes and thinking where I would make corrections.

I made changes slowly following the steps below in order:

Developed relationships with influential stakeholders. Relationships go a long, long, way towards acceptance.
Started writing down requirements and showing them to the business stakeholders. Reactions were "Wow, you really got it" or "This is not what I meant at all, here's what I really meant....". That's the idea, get them to acknowledge what they really want.
Learned the database structure so that my requirements could refer to tables and even specific fields. I know, I know this is not what a BA should do but... with a new IT team it was best.
Produced a detailed spec which was the sole document used for development and QA. All stakeholders were now on one page.

The above was done on a small project. This way I didn't "rock the boat". Since the results were much better than the status quo, my perceived value to the business and IT went up a notch. Since I could now speak a little businessese and ITese I also got some respect.

There was much more to do of course and the four steps above are just general highlights. More details on how to implement them in further posts.....

Focus on Leadership and Improve Your Safety Levels

ronhorton — Tue, 06 Nov 2012 22:05:00 GMT

In the quest to improve safety records, organizations often rely on motivational posters, classes or training programs to help teams minimize risk and improve safety performance. However, great safety records are not achieved through these efforts alone. Improving safety requires leadership – organizational leadership at the front lines that is equipped to develop a process-oriented and disciplined safety-in-execution culture. The secret is training those front-line leaders in a simple, scalable process. The pursuit of operational excellence through such leadership training is the key to improving safety records.

I have always believed that the most operationally-capable organizations are also the safest. Great leadership at the operational level makes organizations excellent. And it is that same great organizational leadership that enables these organizations to improve safety.

In 2007, I was the commanding officer of a nuclear-powered aircraft carrier. That year, our ship won numerous awards, including an award for being the most battle-ready aircraft carrier in the Atlantic Fleet, winning prestigious safety awards and being selected Ship of the Year. We also won three environmental awards and had high retention numbers. We were forward deployed in a time of war; yet we achieved the highest safety ratings.

Operational excellence and safety are not contradictory pursuits. They are both the product of an obsession for continuous improvement, not in the C-suite or boardroom, but where the work is being performed. In the Navy, we call this “deck plate leadership.” The senior leaders onboard our ship were able to improve safety by utilizing organizational leadership and the Flawless Execution℠ methodology – which includes developing leaders, improving day-to-day operations and closing execution gaps.

Organizational Leadership: Leveraging Flawless Execution℠ to Improve Safety

Effective organizational leadership relies on creating an environment and modeling behavior that is conducive to achieving mission objectives. In order to improve safety, leaders must focus on day-to-day operations and closing execution gaps by aligning their teams and building trust on a daily basis. If you focus on improving the day-to-day basic operations of your organization, you will find that your safety records will improve as a result.

There are two principle reasons for this two-fold improvement. First, one must plan well before every task, project or undertaking. Planning does not have to take a lot of time, but it does have to incorporate all of the right elements and be performed in the same disciplined manner every time. Second, teams must assess how well they performed once their plan is executed. Did the team succeed, fail, encounter new challenges, or suffer a near miss? We call such an assessment debriefing. Debriefing is how we learn from doing and how we improve every day. Organizational leadership relies on these basic principles to maintain operational excellence and improve safety. Without these principles, your operations may appear as if they are safe; however, in the long run, you are putting your team at risk.

To improve safety, leaders should follow the Flawless Execution℠ process of Plan, Brief, Execute, and Debrief on a daily basis. Leaders must implement an organization-wide planning process that is simple and scalable at all levels – whether planning at the highest organizational level or for the simplest daily tasks.

After creating a plan, leaders should communicate this plan through briefing. It’s important that the leaders brief what they’re going to do that day. Organizational leadership leverages formal briefings to inform participants of the plan and to describe each individual’s roles and actions within that plan, developing Situational Awareness and aligning the immediate objective with those of the team or organization’s long-term objectives to improve safety levels.

During execution, leaders must hold individuals accountable via a series of short, focused team meetings in which each member is held responsible for his/her duties and execution gaps are identified and acted upon – these meetings ensure that the team remains aligned and focused. Leaders should establish a rhythm of execution that habituates team members to a regular pace of operations so that they know when to expect to perform each of the four steps in the Flawless Execution℠ process. That rhythm provides periodic, expected organizational leadership intersection points that nurtures the discipline needed for both the front-line workers and the deck-plate leaders, which will improve safety and operational excellence.

Finally, the debriefing process allows leaders to create trust with nameless and rankless debrief sessions in which team members develop lessons learned from the execution process. Those lessons learned should be applied to future operations. Leaders should also have a conduit to spread lessons learned throughout the entire organization, which will improve safety and increase performance levels by accelerating the team’s experience.

Leaders must drive the cultural adoption of this Plan-Brief-Execute-Debrief process by applying it to day-to-day operations. Adoption of the Flawless Execution℠ process will effectively close the execution gaps in your organization, which will ultimately improve your safety – and your productivity. Therefore, effective organizational leadership teaches leaders at all levels, the tools, processes and techniques that they need to achieve operational excellence.

Effective Leadership and Individual Responsibility

Afterburner, Inc.

It is a leader’s job to make sure that their team is aligned, and that each member is communicating, working towards the same goal and executing in the same manner. A great leader does not improve safety by simply watching from afar and commanding others. Instead, organizational leadership requires a leader to go down to the front lines with his/her team, whether it’s an oil rig, a paper plant, or a nuclear-powered aircraft carrier, motivating and aligning individuals to accomplish what they’re supposed to, every day. By aligning teams, improving trust, and focusing on day-to-day operations, great leaders will close execution gaps and will finally achieve high safety levels.

Ron "Beav" Horton,

X-Gap: Using Strategic Planning to Close the Project Execution "Gap"

James D. Murphy — Tue, 24 Apr 2012 16:29:00 GMT

Teams and organizations are constantly plagued by project execution errors and failures. These failures create an execution gap -- a gap between what an individual and/or team plans to do and what they actually do instead. Just as retention rapidly degrades after learning, so does project execution after strategic planning. So what can be done?

In 1885, Hermann Ebbinghaus, a German psychologist, famously demonstrated a theory concluding that people start forgetting what they learn as soon as they learn it. In his "forgetting curve" study, he demonstrated that humans forget half of what they learn within an hour of learning it, and by the following day, they have forgotten a full two-thirds of the new information. Since Ebbinghaus' study, psychologists have discovered that there are many ways to improve retention and memory; however, if memory is so fragile, what is its impact on project execution and strategic planning - getting the things done that you and your team should do?

Strategic Planning: The Execution Gap Meeting

Strategic planning is a form of team learning. When approached collaboratively, planning is a knowledge-creating and problem-solving process. And strategic planning can create much detail that is difficult to manage, and therefore, execute. Great project execution requires 100% retention in the team learning process. Without such a perfect level of retention, project execution will falter; however, just as there are techniques to improve individual retention after learning, there are techniques to improve the team's project execution after strategic planning. One of these techniques is the Execution Gap Meeting, or X-Gap.

In principle, the X-Gap is simple. Get the team together at regular intervals during the project execution phase, address the progress of each individual task that must be performed, and take action before progress falls behind. In "Teambuilding: Proven Strategies For Improving Team Performance," recognized as the authoritative work on the fundamentals of team building, the authors note the importance of regular interventions within teams to prevent regression like that of the Ebbinghaus Forgetting Curve. Furthermore, they note that regression is more effectively halted when regular interventions are held to focus on tasks as a team rather than on a one-on-one, supervisor-to-subordinate basis. It sounds like a simple strategic planning technique; however, in practice, holding an effective X-Gap requires discipline.

One of the greatest challenges to leading an X-Gap is controlling the discussion and keeping it on task. Fundamentally, the X-Gap is a transparent strategic planning method of applying peer pressure to enhance project execution performance. So, participants have a tendency to provide excuses and open up lengthy discussions to distract the group from individual accountability. X-Gap leaders must fight this tendency.

Leading an effective X-Gap requires a commitment to four basic principles - focus, resolution, action and frequency.

Principle Number One: Focus

First, X-Gap meetings should be short and focused only on the tasks required. This strategic planning technique is not an opportunity for open discussion, complex problem solving or the exchange of general information. It has only one item on the agenda - the review of all due and open tasks within the plan. In an X-Gap, the leader convenes the meeting on time and proceeds task-by-task through the project by asking each task owner to report their progress. Responses should be succinct. Completed tasks and tasks in-progress but not yet due are simply either "completed," "on track," or "green." Tasks that are in progress but have some uncertainty about the capacity to complete them as planned are "yellow." Finally, tasks that are past due or have encountered some critical obstacle that must be addressed are "critical" or "red." The latter two classifications are the target of the X-Gap strategic planning meeting. The X-Gap leader's purpose is to identify and isolate those "yellow" and "red" category tasks for further review.

Principle Number Two: Resolution

The second basic principle of the X-Gap is to take action to resolve uncertainty, ambiguity and any other obstacles. Once project execution gaps are exposed, the leader should make decisions and possibly reallocate resources in order to close those gaps. Some explanation and discussion is usually necessary. Therefore, X-Gap leaders must remain on their guard against unproductive, rambling discussions. Those responsible for the task targeted for discussion should succinctly explain the issue to the team and state what they believe they need in order to accomplish the task - to close the gap. This need is usually stated as a request for resources or a decision from the leader.

At this point, teams will tend to want to have an open discussion about the matter; however, the X-Gap leader must contain this strategic planning discussion to only a few minutes. If the team is allowed to take too much time, then there will be less time to address other "red" and "yellow" tasks. As a rule of thumb, any task that requires more than two minutes to explain and discuss should be deferred to a separate discussion that takes place after the X-Gap meeting. Leaders must keep the X-Gap meeting focused and moving along smoothly so that all the relevant tasks within the plan are addressed.

Principle Number Three: Action

X-Gap meetings should identify specific actions that must take place during the project execution phase, unless all tasks are completed or on task as planned. Leaders should take care to either clearly indicate the actions that must take place as a result of the task review process, or indicate how and when decisions or other resolutions will take place and who is responsible for them. They must determine whether or not additional resources are required, who will acquire them and by when. And if further deliberation is required to achieve a decision, leaders must decide when this will take place and which team members will be a part of the discussion. Successful strategic planning in X-Gap meetings should never conclude without clarity about the next steps to take.

Principle Number Four: Frequency

Finally, X-Gap meetings should be a recurring strategic planning event that aligns with the team or organization's overall project execution rhythm. If the team holds an X-Gap every Monday morning at 10 a.m., for example, the team will be better able to anticipate, participate more fully, and prepare more thoroughly.

Preparation is the key to a successful X-Gap meeting and strategic planning session. Team members report to the X-Gap at their pre-designated time and place with the statuses of their assigned tasks in the plan. This means being prepared to respond to its overall status, as well as providing both a succinct description of a status that is "yellow" or "red." Participants should be prepared to answer the question: "What do you believe is required to move forward?" Of course, there are often certain dependencies outside an individual team member's control that may be the underlying cause. Hence, the purpose of the X-Gap is to expose these project execution issues and address them appropriately as a team. Good preparation also means that individuals can stand in for others unable to attend the X-Gap, providing a status of their tasks and discussing what is needed to move forward.

An X-Gap strategic planning meeting must be led. As a teacher leads a classroom and utilizes techniques to help students improve retention, a leader should utilize techniques like the X-Gap to improve project execution.

James D. Murphy,

Founder and CEO of Afterburner, Inc.,

Collaborative Leadership: A Process for Success in a Turbulent World

James D. Murphy — Mon, 12 Mar 2012 16:45:00 GMT

Do you know how to provide collaborative leadership in a disciplined fashion? And how does one define disciplined collaboration? The current business and leadership literature touts the importance of collaborating in our turbulent world. Large and small businesses and teams struggle to wrap their heads around just what collaboration is. Many see collaboration or collaborative leadership as a challenge that can be met through technology, whether it is through social media or virtual conferencing, while others recognize the benefits of restructuring an office space so that it appears more open. However, technology and physical space are only superficial means to address the challenge of disciplined collaboration. Collaboration - and successful collaborative leadership - does not derive from "where" or through "which" media people interact. Instead, it is about "how" people interact. And that "how" must be disciplined.

Disciplined Collaboration

Disciplined collaboration holds a central place in Jim Collins' latest work, "Great by Choice." "Great by Choice" is the result of a grand research project that seeks to discover how some companies have continued to thrive in spite of uncertainty, chaos, and luck - good or bad. It's a centrally-important issue in our turbulent world, where change is so rapid and unpredictable. Collaborative leadership has been cited as a vital skill that teams and companies must use in order to constantly create, innovate and adapt to change. Innovation is often seen as the fruit of collaboration; however, this is a dangerously limited perspective. Collaboration is much more valuable than a means to achieve innovation. Disciplined collaboration is an invaluable process that teams can utilize to successfully innovate, solve problems, make decisions, plan and execute.

Above all, disciplined collaboration is a creative planning and decision-making process. In "Great by Choice," Collins defines discipline as "consistency of action." For teams and companies, Collins' definition implies that collaboration and collaborative leadership processes be consistent. "The great task, rarely achieved," Collins writes, "is to blend creative intensity with relentless discipline so as to amplify the creativity rather than destroy it." He goes on to point out that "the signature of mediocrity is not an unwillingness to change; the signature of mediocrity is chronic inconsistency." That inconsistency begins in the planning and decision-making process. And in a world of complex challenges that are best met by teams rather than individuals, that consistency requires a disciplined collaboration process.

Dynamism and Iteration

A disciplined collaborative planning process requires certain elements. Altogether, there are many elements in a planning process; however, some of the elements most successfully impact an effective collaborative leadership process -- these are the elements that allow the process to be dynamic, iterative, participatory and cognitively diverse.

"Dynamic" refers to the adaptability of the planning processes product -- the plan. Change happens; therefore, you shouldn't collaborate on a plan only to find that the plan needs to change without a clear process of making those adaptations.

The process for disciplined collaboration and collaborative leadership should also be iterative. Iteration is similar to dynamism, but is not the same. Iteration is the plan improvement process within the overall planning process, while dynamism refers to the adaptation of the plan after it is executed. Iteration occurs during planning, while dynamic adaptation occurs during the execution of the plan. Teams that collaborate during planning, and those who utilize collaborative leadership, will iterate the plan before its execution, enabling those individuals to more effectively execute and adapt those plans.

Nominal Group Aggregation

Of course, disciplined collaboration requires participation by more than one individual - this is what makes collaborative leadership so challenging. How do a group of individuals come together to produce a plan or make a decision? Fundamentally, it requires a collaborative leadership process for generating ideas at the individual or very small group level (2-5 persons), and then combining and vetting these ideas at a larger group level (5-15 people). This process is called nominal group aggregation.

Nominal group aggregation is a delicate process because everyone has their own ideas - some better than others. In collaborative groups, some individuals voice their ideas forcefully, while others hold back on valuable insight, fearing they won't be heard or appreciated. However, successful collaborative leadership techniques can overcome such obstacles, and these techniques must be part of a disciplined collaborative process. Disciplined collaboration is not about achieving consensus; instead, it is about producing the best plan to achieve the objective. Consensus can lead in any direction, while disciplined collaboration yields a plan that leads in the right direction.

Cognitive Diversity and Simplicity

Finding the correct direction to proceed requires another element of the collaborative planning process: cognitive diversity. Collaborative leadership will not be successful if you are collaborating with a team of individuals that think alike, have similar backgrounds and experience, occupy the same hierarchical positions, and so forth. Creativity and innovation require divergent thinking and dialogue. Therefore, disciplined collaboration must adhere to a process that harnesses cognitive diversity. Utilize your collaborative leadership skills to incorporate a balanced mixture of experience, knowledge and positions for the collaborative process. Consider that two heads are actually not more valuable than one if both heads think alike and see the world in the same way. For example, to a hammer, everything looks like a nail - so make sure that you have a complete toolbox when planning collaboratively.

There is one additional important element. The process must be simple. To collaborate effectively and efficiently, people need a simple process. If a team has to spend time organizing and training about how they are going to collaborate and then struggle to become proficient at that process, then efficiency and effectiveness suffer. Collaborative leadership entails using a process that is simple to learn and apply, consistently applying that process throughout the organization. Disciplined collaboration will become a widely-practiced behavior; and that behavior will ultimately become a healthy collaborative culture.

Achieve Collaboration through Discipline

Disciplined collaboration yields more than a plan or decision; it engages the team to execute successfully. Disciplined collaboration is the first step in achieving success as a team. Humans like to be autonomous, to have the freedom to solve problems and perform tasks on their own and in their own way. However, our complex, turbulent world requires collaboration in order to create, innovate and succeed. Humans also need to be connected to each other, to be a valuable part of a larger whole. Disciplined collaboration is the key to satisfying these often conflicting needs in modern organizations. On one hand, collaborative leadership provides each individual with the opportunity to contribute their own insights and then, once a final plan is created, to go forth and execute in their own semi-autonomous way. On the other hand, what each individual executes becomes a well-coordinated part of the overall objective. However, to fulfill these basic human needs, the team must always achieve collaboration through a disciplined process.

James D. Murphy,
Founder and CEO of Afterburner, Inc.

Simplicity and Elegance: Expressing Your Core Competencies

James D. Murphy — Wed, 07 Mar 2012 19:48:00 GMT

Do you know what your business's core competencies are? Is there just one or are there many organizational attributes? If you answered that there are many, how would you describe them succinctly? Core competencies are one or a combination of a few unique or rare abilities; however, a description of core competencies is not simply a laundry list of various organizational attributes. It seems like a simple task, but naming your core competencies can be very difficult. This is because we, as business leaders or managers, get caught up in the tactical day-to-day tasks that we accomplish and we often mistake those tasks as our core competencies.

Years ago, when I walked to the flight line to take my first solo flight in an F-15 fighter, I was struck by an all-encompassing passion that has driven me and everyone on my team to achieve success. That passion was to define and teach the basic principles that helped me, a farm-boy from Kentucky, become one of a very few elite U.S. Air Force fighter pilots. Every individual on my team shares that passion, whether they are a fighter pilot, a U.S. Navy SEAL, a U.S. Army Ranger, Delta Force, or Special Forces operator, or one of many other classes of elite military professionals. We've built a great company. But we've done that with a clear understanding of our core competencies and organizational attributes that have guided us for years.

Defining Your Core Competencies: Examining Your Complex Organizational Attributes

Often, your true core competencies are elusive and hard to pin down, which makes defining your core competencies difficult, even when examining your organizational attributes. However, it is my belief that an expression of your true core competencies can be articulated both simply and elegantly.

Expressing core competencies is about getting to the root cause of why you do what you do and what makes you successful. A core competency is not a mission or vision statement; nor is it a statement of competitive advantage. It is not a statement of the level of quality of the products you manufacture or of the services you provide. A core competency is something more fundamental. It is both a root cause of success and an expression of the organization's unique character or reason for being. A simple and elegantly expressed core competency is a summary of what is most likely a set of complex organizational attributes.

Proof of the complexity of a core competency can be found in the way scholars in the field of business management and leadership have defined the term. In their 1990 Harvard Business Review article entitled "The Core Competence of the Corporation," C.K. Prahalad and Gary Hamel assert that an organization's core competencies can be attributed to success in a wide variety of markets, increase the perceived value to the customer, and prevent imitation by competitors. The authors conclude that these benefits are due to a "complex harmonization" of organizational attributes, creating core competencies.

How Passion Contributes to Core Competencies

Jim Collins famously characterized core competencies as "hedgehog" traits in his book "Good to Great." Instead of describing core competencies in terms of benefits, Collins describes them in terms of three dimensions - what you can be best in the world at; what drives your economic engine; and what you are deeply passionate about. Although each is important, it is often the last "dimension" that is left out of an organization's description of its organizational attributes. What you are passionate about is a core competency -- it's the fire in your belly that drives you to do every day what must be done. Without that passion, descriptions of core competencies are simply statements of what you do well, and do not include what you love. Describing the passion that drives your organization is essential to cutting through the complexity and getting to the simple and elegant truth of the organization's identity.

The science of physics provides an excellent example of simplicity and elegance. Physicists are often driven to refine their theories until they achieve an "elegant" formula. Physics is an elegant science because it seeks to find the fundamental laws of the universe. For this reason, physicists call these laws "elegant" because they are, in essence, both simple and effective.

For example, consider the famous formula E=mc². This formula simply states that energy is equal to mass times the square of the speed of light. This simple formulation was one of the most significant scientific discoveries of the past century - and it is expressed in just five symbols. Pick up any high school physics textbook and you'll find a host of simple equations that explain almost any phenomenon we encounter in the course of our everyday lives. That simple but powerful formulation is what physicists mean by "elegant."

It is essential to include the passion - your organization's "reason for being" - found within your organizational attributes, in a statement or written formulation of your organization's core competencies. Passion is a core competency that is often overlooked. Like other core competencies, passion cannot be duplicated easily. It is important, then, to expand the scope of the core competency to become more than just a statement of fundamental skill. Capture the passion and include the guiding principles - what the organization believes. Altogether, core competencies, core beliefs and the passion to do what it is that you do, come together to create the simplicity and elegance of what I call the "organizational imperative."

Organizational Imperative

Many companies do a good job of capturing the essence of their organizational imperatives by developing eloquent and inspirational mission, vision and goals statements. However, this is an awkward approach, as it usually fails the test for simplicity and elegance, and it may lack a true statement of organizational imperatives altogether.

If you correctly define your core competencies, you will realize that everything your organization accomplishes, along with its organizational attributes, should flow from and connect directly to that description. Furthermore, that definition should become a screen for every decision, however large or small, throughout the entire organization.

My company's organizational imperative is simple and elegant. It is as follows:

"To relentlessly seek to accelerate individual, team, and organizational performance through the inspiration and experience of elite military professionals. Our guiding principles are: (1) seek integrated solutions with transformative power that are simple and achieve results; (2) represent our brand - Flawless Execution; and (3) do right, speak the truth, and demonstrate excellence."

In just 50 words, we have described our passion, our core competencies, our organizational attributes and our beliefs.

Like an elegant formula in physics, a complete and concise organizational imperative describes your organization's behavior. It is the standard to which all actions are executed and decisions are measured and made.

About the Author

James D. Murphy

Founder and CEO of Afterburner, Inc.

Organizational Gravity: Three Steps to Foster Continuous Improvement, Defy Obsolescence and Take Flight

James D. Murphy — Thu, 12 Jan 2012 17:10:00 GMT

Gravity can be a wonderful thing. It is an irresistible force that keeps us grounded on this big, beautiful, floating blue marble. It is even applicable to organizations in the form of organizational gravity. For example, I worked with an organization that coined a catch phrase for a challenge beyond its scope of control, deeming the situation a "gravity issue." They explained that "the situation is out of our control, much like gravity - you can't do anything about it."

Sadly, this mentality represents the culture in many organizations. Whether it's the culture, the hierarchy, the bureaucracy or the processes, organizational gravity seems to grow ever stronger as an organization matures. Sure, organizational gravity keeps the organization grounded and focused. It may also contribute to a passion for continuous improvement at a very tactical, discreet level. But, it also narrows that focus at the expense of innovation and adaptability, two of the most critical abilities of successful organizations. So how do we defy organizational gravity?

Continuous Improvement Planning

Every company or organization begins as a plan. Never forget that! Continuous improvement planning is the key to defying organizational gravity. It's easy to think of everything we do in our working lives as "processes." For instance, your organization probably has a hiring process. However, this is the wrong way to look at it. Instead of viewing it as a hiring process, think of it as a hiring "framework." Of course you plan for each and every position that you must fill, as every new hire has different strengths and weaknesses. However, many organizations still call this a "process," which evokes the image of a manufacturing line.

What about a new project? Any continuous improvement planning in that? Sure there is. Large scale projects are unique, even if there are a number of processes involved, because in a sense, these projects have never been performed before. If you are an entrepreneur pursuing a new business idea, you begin with a plan. That plan may be a formal business plan or it may just be an idea sketched out on the back of an envelope. Ultimately, with success, those plans transform into processes, the sustaining framework of the business -- and that is where organizational gravity begins to tighten its grip. As our ideas coalesce into plans and the plans further coalesce into concrete processes, organizational gravity strengthens and holds the organization together.

It is this necessary and proper transformation from plan to process that, for good and ill, perpetuates the relentless assault of organizational gravity. As a positive force, we might call it focus. However, the cons of organizational gravity include stagnation and paralyzing bureaucracy. How do we balance the need to "break the surly bonds of earth" to adapt and innovate in a constantly changing environment with the grounded focus of organizational gravity?

Three Tasks to Defy Organizational Gravity

Freeing ourselves from the constraints of organizational gravity while anchoring ourselves safely in the terra firma of our proven processes takes a constant commitment to accomplish three tasks: Always state a clear objective, always align every objective to your purpose, and always plan over the process.

Have a Clear Objective

The objective is everything! I often observe individuals and teams charging forward to execute a task or project without a clear objective in mind. They get caught up in doing without thinking, and if you stop these individuals to ask what the main objective is, they would have a very difficult time articulating what it is they are attempting to achieve. However, if you ask them to think clearly about their objective, they often realize that their approach is flawed or even wrong.

Always have a defined objective for even the most routine tasks. This will help you think freshly in terms of the continuous improvement process. Consider how you will achieve the objective and question whether a given process or approach is really sufficient, effective, or relevant.

The Big Picture Objective: Differentiate the "Why" from "What"

Align to the big picture objective -- the big picture objective refers to your purpose, mission, strategy and long-range goals. Simon Sinek, author of "Start with Why," makes this compelling point: Aligning to the big picture purpose, or as Sinek puts it, the "why you do it," is what separates Apple from companies that make computers. Making something or providing a service is just the "what," and the "what" may change as the environment or market changes. However, the "why" never changes. The "why" helps us look beyond our terrestrial existence and the organizational gravity, helping you to re-align to the fundamental reasons why we and our organizations get up every morning. When you constantly remind yourself of the "why" and align your actions to the big picture, you simultaneously free yourself from constraints of process-thinking while grounding yourself in the fundamentals of the organization.

Plan Over the Process

Third, always plan over the process. The Blue Angels, the U.S. Navy's world famous flight demonstration squadron, fly the same show on every performance, but the location changes. Do you think that the Blue Angels fly a process? No, they fly a continuous improvement plan that they adapt to every different location, situation and changing weather condition. Unless you are manufacturing the same widget day in and day out, you need to plan over the process. And I guarantee that you won't manufacture that widget the same way for too many years. Change always happens -- like organizational gravity, it's relentless.

One can plan over the process by taking the standard process, clarifying the present objective, aligning that objective to the big picture objectives and fundamental "why" of the organization, and then asking a few questions. First, ask what stands in your way - what threatens the successful accomplishment of your objective? Second, ask what resources are needed to accomplish this objective. Existing processes fool us into making assumptions about threats and resources - that they remain the same day-in and day-out. Never assume that a process may be followed blindly without considering what may have changed in the current context. Instead, plan over the process - never assume a process is sufficient in every given scenario. Always perform fresh continuous improvement planning by considering new threats and resources and then develop a new course of action appropriate to the present context.

Balancing the benefits and limiting tendencies of organizational gravity comes down to maintaining a clarity of purpose, approaching every task, every project, and every day as an opportunity to conduct continuous improvement planning.

James D. Murphy
Founder and CEO of Afterburner, Inc.

Executive Coaching and Debriefing for Corporate Leadership Development Programs

James D. Murphy — Mon, 19 Dec 2011 19:53:00 GMT

In today's management environment, new forms of and tools for corporate leadership development programs have emerged. One of the most popular development tools is executive coaching. The number of executive coaches has more than doubled in the past decade and corporate leadership development programs are utilizing their services more frequently. However, the fundamentals of executive coaching have actually been around for many years in the form of debriefing.

In the U.S. Air Force, debriefing after every flight was an essential process in my training and development as an F-15 fighter pilot. My instructor pilot debriefed with me after every training flight. Later, when I became an instructor pilot and squadron training officer, I did the same with my young pilots. After leaving the Air Force, I used the basic tenets of the debriefing process I had learned, adapted the process to a sales force I led in a civilian company, and further refined that process over the next 16 years.

I was recently reminded just how broadly applicable the debriefing framework is as an executive coaching tool when a professor approached me at the end of a lecture to a healthcare team, thanking me for explaining the process of debriefing to the team. She told me, "You've given me the means to have a difficult conversation with a student, allowing her see what, in herself, needs to change in order for her to be successful."

Corporate leadership development programs require both executive coaching and debriefing practices, processes that utilize complex discussions and deep analyses that resist oversimplification. Executive coaches help their clients to see themselves more accurately, allowing clients to establish actionable objectives for personal change. Likewise, debriefing helps individuals and teams more accurately analyze the work that they have done in order to make efforts to improve upon their past initiatives. While executive coaching focuses upon the individual, proper debriefing is effective in both individual and team development. The principles are the same, but for the debriefing process, the approach is more direct, objective, and simple.

Differences Between Executive Coaching and Debriefing Practices

Although corporate leadership development programs draw from both executive coaching and debriefing practices, there is a significant difference between the two processes: First, executive coaching practices struggle to get to the actionable objectives for change. This is where the highly subjective talent and skill of the coach comes in to play. Second, coaching is less process-driven than proper debriefing. Successful executive coaching is dependent upon the individual style and skill of the coach and the character traits of their client. Successful debriefing, however, is driven by a repeatable, structured process.

Let us examine some of the elements of a good debriefing process and compare them to an executive coaching practice. The first of those elements is what we call "tone." In the debriefing practice, setting the right tone is critical. The right tone is nameless and rankless, which gives everyone an equal footing. Amy Edmondson, Novartis Professor of Leadership and Management at Harvard Business School, has labeled such a tone "psychologically safe." In executive coaching, a coach will take care to establish a trusting and psychologically safe tone much like a professional therapist or physician would for a patient. This tone is essential in order to achieve the honesty and truthfulness necessary to identify objectives for change. In debriefing, the proper tone is critical to uncovering mistakes and isolating successes.

Corporate leadership development programs also require the correct tone. With the right tone, debriefing and executive coaching practices can enable teams and individuals to find the truth. In the executive coaching practice, obtaining the truth of how others see or perceive the client can be a tough process, which is typical of the analysis of any complex issue. This is the same in the debriefing practice. Whether we're debriefing a team or an individual's performance, we have to be prepared to dig deep into the root causes of both successes and errors. In order to do this, we only use the debriefing practice for clear and measurable objectives. One cannot debrief in any truly successful and meaningful way without specific and quantifiable objectives.

Utilizing Clear and Measurable Objectives

In our corporate leadership development programs, we emphasize the importance of stating clear objectives in both executive coaching and debriefing practices. Clear objectives allow the debriefing process to take two procedural steps in order to discover the root causes. First, we take a look at how well we executed toward our stated objectives - did we do what we said we were going to do? Did we execute this process in the way that we said we were going to do it? Take a look at each of the tasks we had to perform in order to meet our objective(s). Was each of these steps effective? From this inquisitive process, we are able to create a short list of successes and errors that form the basis of our next step: analyzing the execution.

We analyze the execution by taking each of our results – the successes and errors – and subject each to a series of "why's" until we get to the root cause. We continually ask "why" until we get to the fundamental root cause: Why did that happen? What really failed? Did we just get lucky? We can't fix something, replicate a success, identify a near miss, or address a personal shortcoming until we know exactly what needs to change and why.

The Importance of Actionable Feedback

As soon as we know what that root cause is, we can get to the real point of debriefing and executive coaching - taking corrective action. We need actionable feedback in order to improve ourselves. Corporate leadership development programs help to continuously improve teams and organizations by requiring actionable feedback. Research demonstrates that feedback that is not actionable can actually result in negative behaviors. The product of debriefing and executive coaching must focus upon what can be done to address the root causes. Without a specific course of action, reflective activities will be a waste of time at best, and can potentially trigger negative behaviors at worst.

An effective debriefing process develops an actionable lesson learned that addresses each of the identified results - each success or error. A lesson learned is a set of steps intended to resolve the error or replicate the success of each of the root causes. It is an objective and clear set of instructions or actions necessary to improve personal, team and organizational performance in the future. Furthermore, in the context of team debriefing, it assigns a single accountable individual to take that set of actions or to properly store the learning for future use.

Such are the basic processes, utilized by corporate leadership development programs, for both debriefing and executive coaching. However, there is one final secret to successfully using these practices. In our corporate leadership development programs, we recommend performing these processes frequently and in small, achievable portions. Successful executive coaches help clients to tackle personal goals a little at a time, meeting with individuals to assess incremental progress relatively frequently, typically every two weeks. The debriefing frequency should also follow this timeline. If debriefing occurs less frequently than once per month, the individual or the team is likely to "choke on the elephant." It is hard to change, especially when you are attempting a great amount of change in a short period of time. Aim to change slowly, a little at a time. This is the same philosophy behind successful change methodologies.

Conclusion

There is a deep, meaningful correlation between the debriefing and executive coaching processes. James Hunt and Joseph Weintraub, Babson College of Management professors, argue that facilitated learning, such as executive coaching, is leveraged to extraordinary results through forms including the U.S. Army's After Action Review (AAR) and the U.S. Air Force's debriefing process. Both executive coaching and debriefing are forms of facilitated learning, and both are utilized in successful corporate leadership development programs. However, in executive coaching, a third party facilitates the learning for one member of an organization. But the debriefing process allows the team to facilitate learning for individual team members and the organization as a whole.

James D. Murphy,
Founder and CEO of Afterburner, Inc.

The Red Team: A Simple But Effective Method to Improve Mission Planning

James D. Murphy — Thu, 27 Oct 2011 12:59:00 GMT

The May 1, 2011 mission to find Osama Bin Laden has become one of the most celebrated military mission planning successes in recent memory due to the utilization of a little-known and seldom-used practice called the Red Team.

The mission was a daring raid executed by the courageous members of the U.S. Navy SEAL DEVGRU, also known as SEAL Team Six, especially when considering the potentially disastrous political and diplomatic consequences that would have occurred had the mission failed. In spite of the dangers, the odds, and the loss of one of the two Blackhawk helicopters that delivered the SEALs to the target, the mission to get Bin Laden was an extraordinary mission planning success that continues to inspire awe. The Bin Laden mission was executed by some of the finest warriors that history has ever known. However, aside from skill in the profession of arms, it was the overall tactical planning process that went into the mission that provides an important lesson for planners in all fields - in military, business, or in everyday life.

The Overconfidence Bias

We fall in love with the plans we make. Mission planning is much like giving birth to a child. When the plan is complete, whether developed by an individual or a collaborative team, the planners can step back and congratulate themselves on the genius of the plan that they have created -- such overconfidence is one of many cognitive biases we humans fall prey to.

This is why the practice of utilizing a Red Team is necessary. A Red Team is a simple means to overcome the overconfidence bias and the theory of "groupthink," the need for groups to seek conformity and unanimity in planning and decision making. The mission planning effort that went into the Bin Laden mission was the detailed product of many different planners, but that alone was not enough to ensure success. The tactical planning process had to be subjected to a Red Team.

The Role of the Red Team

For the Bin Laden mission, military planners invited an outside group of experts who were previously unaware of the plan and had not taken part in the mission planning process to comprise what we call a Red Team. A Red Team examines a plan and offers frank criticism of the plan without bias. The Red Team's purpose is to expose flaws or weaknesses in the tactical planning process - to test the plan with dispassionate reason and respectfully offer detailed criticism. However, the planners must accept the criticism humbly, without commenting or defending the plan. It is vital that the planners involved are able to accept and incorporate this criticism, or the practice of utilizing a Red Team will be rendered moot.

Historical Examples of Mission Planning Using Red Teams

The Red Team is not a new concept. In 1962, faced with the threat of Soviet nuclear missiles in Cuba, President John F. Kennedy utilized a form of the Red Team to great success. He had suffered a terrible and embarrassing debacle in the botched Bay of Pigs Invasion and Kennedy was not going to allow such an error in mission planning to happen again. He began by dividing his Executive Committee in half and tasked each of the two groups to argue for one of two primary options to deal with the threat. One group argued for a naval blockade and the other for an air strike. Kennedy then had the groups switch positions and critique the other group's proposal. The last step in Kennedy's tactical planning process was to ask his brother, Robert Kennedy, and one of his close counsels, Ted Sorenson, to act as a Red Team on each group's proposal. The result was one of the most masterfully played moves during the Cold War - a naval blockade that forced Soviet withdrawal of nuclear missiles from Cuba.

The Red Team has been utilized with great success in the U.S. military. During the Gulf War mission planning effort, planners employed this practice, asking Red Team members to defeat a proposed plan. Planners then took the weaknesses exposed by the Red Team and improved the tactical planning process, making plans tighter and nearly foolproof. The result was a successful war fought on foreign soil to expel invaders in just five weeks - a mission accomplished with minimal loss of life and destruction of property. Like the Bin Laden mission, the Gulf War met with success through the use of a tactical planning process that included Red Teams.

Eliminate the Fear of Personal Attacks When Using a Red Team

One might think that it takes courage to employ a Red Team. It is hard to expose your "baby" to such criticism, as we naturally view critiques as a personal attack. However, when performed correctly, a Red Team need not invoke fear of personal attack. The secret to successfully incorporating this practice into the mission planning process is to diffuse resistance to personal criticism before the Red Team critique takes place. Individuals must incorporate the idea that "it is not 'me' that is being assaulted by critics, it is 'us.'"

To further ameliorate the sense of offense and fear that the Red Team may create, this part of the tactical planning process should take a simple, disciplined and respectful structure. Invite the Red Team to sit down while someone from the mission planning team briefs the plan to the room. After the plan has been detailed, the Red Team should then have an opportunity to ask clarifying questions. After all questions have been asked, the Red Team should offer criticisms of the mission planning process in a round-robin fashion until all concerns have been voiced.

Offering and accepting criticism is much easier when it is communicated correctly. All members of the Red Team should begin their critical remarks with a statement such as, "Have you considered..." Furthermore, all responses to Red Team criticisms should be grateful, beginning with statements such as, "Thank you for your input." There should not be discussion or defense. The mission planning team will have a natural tendency to want to argue with the Red Team about their tactical planning process and will have to avoid the urge to defend the plan and learn to respond with gratitude.

Because the Red Team has no prior knowledge of the tactical planning process and also lacks knowledge of the considerations that were part of the mission planning effort, beginning each comment and criticism with the aforementioned "Have you considered..." statement is vital. This relieves the mission planning team of the need to respond and also relieves the Red Team from concern that a comment or criticism will not be valid. After pointing out the flaws and weaknesses in the tactical planning process, the Red Team should depart and the mission planning team should begin incorporating the newfound criticism to better the plan as a whole.

The Red Team utilized during the Bin Laden mission provided invaluable input as a critical component of the mission planning process. This practice can improve any plan, in any context and in any company. The best part is that utilizing the practice does not take much time, as a Red Team requires a minimum of only three or four members to discuss the tactical planning process. The meeting is also short, at approximately 30 - 60 minutes - and the results can make a world of difference.

James D. Murphy,
Founder and CEO of Afterburner, Inc.

Thirteen Elements of Effective Planning

James D. Murphy — Wed, 21 Sep 2011 19:18:00 GMT

All plans are not good plans. In fact, even good plans can fail. We cannot predict the future – we can only imagine it imperfectly. In our companies and organizations, effective planning is a social activity. Deciding on a strategic planning process as a group, rather than as an individual, adds even greater complexity to an already complex task. Collaborative and effective planning techniques, then, require 13 essential elements.

1. Effective and Strategic Planning Process

First, effective planning requires a process, and that strategic planning process should include the remaining 12 elements of good planning. In collaborative team planning, that process must be structured and disciplined in order to be efficient and thorough. Without a process, your planning techniques will be awkward, inefficient and often insufficient.

2. Effective Planning Techniques: An Envisioned Future / Objective

When we envision the future, we must describe it clearly and provide specific measurements in order to judge our success. To this end, the objective of our effective planning techniques is the goal we envision attaining in the future. Objectives must be clear to all involved. They must also have a scope that is commensurate with the span of control of those involved with the effective planning process. An objective that is not achievable by those tasked with developing a plan is, obviously, doomed to failure. Objectives must also be measurable. Without measurements of success, there is no means of establishing whether or not the objective was achieved, and your strategic planning process will be flawed.

3. Dynamic, Adaptable Planning

In terms of effective planning, "dynamic" means that plans are adaptable, in two ways. First, the act of effective planning considers the current and predicted environment and adapts the plan accordingly. Second, in the strategic planning process, plans must be devised in such a way so that they are not overly detailed. Effective planning ensures that your plans can adapt to changes that occur while the plan is being executed.

4. Iterative Improvements

Effective planning at your organization will also be iterative. By "iterative," we mean that a plan will improve continuously from one iteration, or version, to another before it is executed in the strategic planning process. The iterative nature of planning supports its adaptive or dynamic nature. Iteration can be sped up by an effective planning technique known as "Red Teaming." In Red Teaming, a group of individuals outside the planning effort are invited to criticize the plan or expose its weaknesses, acting as a form of rapid iteration and improvement.

5. Effective Planning Requires that You Learn from Experience

A complex and rapidly changing environment demands the ability to rapidly learn from the changes in that environment. Even the most well-educated and trained organization will soon become obsolescent as changes in the environment eventually overwhelm it. Good organizational planning requires sophisticated and effective planning techniques that the organization learns continually, through interaction with its environment and the execution of its plans.

6. Means to Achieve / Course of Action

The central element of all effective planning techniques is the Course of Action (COA). These are the actual tasks that must be completed, whether in parallel, in series, or a combination of both, to achieve the goal. For the most part, in a strategic planning process, the Course of Action, for simple plans, is intuitive or even obvious. However, for most organizations, plans may require great detail. Therefore, an effective planning process must be flexible enough to handle both simple and detailed plans. Effective planning processes should have the ability to repeat the planning process at successively lower levels in the organization, while supporting the objectives of the overall plan.

7. Decentralized Effective Planning

Another effective planning technique is the decentralization of plans, closely related to the flexible and successively repeatable nature of the Course of Action. Effective planning teams should not plan beyond their scope or expertise. In other words, the executive team of a large corporation should not develop the details of a strategic planning process to replace a main server in their IT infrastructure. Such a task is both out of their scope and, most likely, their expertise.

8. Individual Accountability

The scope and detail of effective planning is concluded when each task within a Course of Action is assigned to a single individual, not a team, to complete. Without individual accountability to each task and each plan, there is a significant risk of miscommunication, misunderstanding, and ultimately, failure.

9. Effective Planning Techniques Support Initiative and Good Judgment

General George S. Patton said that plans "[...] should be made by those who are going to execute them." Decentralization and accountability go far in supporting the success of effective planning techniques. However, when a strategic planning process is developed by the team responsible for accomplishing the plan's objective, the overall quality and likelihood of creating a successful plan improves exponentially.

10. Consider Resources

Effective planning means not committing to or wasting resources unnecessarily. In a strategic planning process, planners must determine the appropriate targets or objectives and focus resources upon those objectives. Because resources are often limited, prioritizing and planning successive phases of implementation may be necessary.

11. Assess Risk: Leadership Responsibility

Resources are considered carefully at every level of effective planning. Furthermore, the assessment of objectives, threats and resources are critical steps in every strategic planning process that, when taken together, form the basic risk assessment for any plan. Without the necessary resources to either avoid or mitigate the threats to accomplishing an objective, the risks in undertaking that plan should be given due consideration by the leadership within the organization. Because risk is often necessary, the final decision to execute the plan is left to its leaders, not the planning team.

12. Participatory and Cognitively Diverse

Isolating effective planning in a single individual or a group of individuals without the benefit of field experience and a diversity of knowledge, skills, and abilities is a recipe for failure. The world we live in is increasingly complex. Problem-solving in our complex world requires teams of cognitively diverse individuals contributing their unique knowledge to form a combination of effective planning techniques. If effective planning is conducted by a single individual or by groups of people with similar knowledge, skills and abilities, the qualities necessary to solve complex problems and to create an innovative strategic planning process will be absent.

13. The Most Effective Plans are Simple

The more complex a plan, the more likely it will fail. As Statistical Process Control and Six Sigma methodologies instruct, the greater the number of steps in a process, the greater the potential for a defect. That is why it is critical that the effective planning process remains simple. Simplicity is not just about minimizing the number of tasks, it's about making sure that each task is clearly defined through answering some simple questions: "who will do what and when."

There is a paradox at work in effective planning. It is simply this: that our human tendency is to implement plans rigidly while the purpose of a plan, in light of the complexity and constant change in the world, is to define objectives and establish a point of departure to react to change. The paradox of the strategic planning process is that effective planning does not involve merely creating a list of sequenced tasks, but establishing a constantly evolving problem-solving process that adapts and thrives in the environment.

James D. Murphy,

Founder and CEO of Afterburner, Inc.

The "R" Word

David Wright — Wed, 10 Aug 2011 04:11:00 GMT

Software is a uniquely new invention, different than anything else we humans have come up with in the past. ...

"The software-controlled electronic information system is fundamentally different from physical labor-saving devices such as the cotton gin, the locomotive, or the telephone. Rather than extend the ability of hand motion, leg motion, or the ability to hear and speak across distances, ITsystems extend the capabilities of the mind—to think, to organize and disseminate information, to create."

David R. Brousell
Editor-in-Chief
Managing Automation Magazine
New York, October 2001

To me, this means that it is inherently difficult to know what some software should do, because it can do whatever you need it to. ... but what do you need it to do?

That is the question, isn't it?

“… the hardest single part of software development [remains] deciding precisely what to build."

Fred Brooks
Author of the 1986 paper "No Silver Bullet”

I keep saying "needs", because the term that is actually used in software development is a lightning rod for debates.If you have been kind enough to read this far, you knowI am talking about "Requirements".

If you are going stick with me going forward, you will see that I am a firm believer that efficient and effective requirements discovery is a key contributor to successful deliveryof good software. It is not the only contributor to success, but it is part of the mix. I do know that bad or non-existent requirements are a pretty good predictor of a failureto deliver good software.

The real issue of interest is what is a requirement. The answer is multi-faceted and of course still a subject of debate, but that keeps things interesting and worth writing about.

Effects-Based Thinking Part III

James D. Murphy — Tue, 09 Aug 2011 19:15:00 GMT

In Part I of this series, I introduced the concept that, from the perspective of complexity, everything exists within a system. In Part II, I outlined a three-tiered framework of effects-based thinking (EBT) and planning that is critical to understanding how change propagates throughout these complex systems - the organizations, markets and communities in which we all live and work. In this final installment, I will explore how effects are planned and initiated within complex systems and how cognitive, adaptive leadership propels those effects.

Effects-based thinking transmits through systems in three orders - kinetic, second and third order effects. Kinetic effects describe the objectives of short-range operational plans - the plans and projects we carry out on a daily basis in our work. These objectives must be clear, measurable, and achievable and must support the organization's overall objectives. Although a plan or project may take some time to complete, its effects should be immediately observable and measurable. That's the kinetic effect of effects-based thinking - a small but significant step toward a larger goal (i.e. second and third order effects).

But, the kinetic effects we seek to create must have another quality. That quality is what we call "line-of-sight alignment" or "adaptive leadership." Adaptive leadership is a clear understanding of the actions that need to be taken now to affect change over the long term and achieve the effects desired at the third order of effects-based thinking. It's simply understanding how what you do today most likely affects the future. It's a clear line of connection between kinetic, second and third order effects - or daily operations, strategy and organizational mission and vision. Examples of adaptive leadership are thinking about the fact that the customer service I provide today affects the store's bottom line at the end of the month and supports the long term success of the business and considering that the investment I make in the new leadership development program today will stem the outflow of experience from the retiring Baby Boomer generation over the next few years, and will build a firm foundation for long-term growth and success. With effects-based thinking, we are well-equipped to make the daily, weekly and monthly actions necessary to get these results. Adaptive leadership also helps develop a more keen perception of the system as a whole.

iPods, Assassination, and EBT

The intended impact of adaptive leadership and multiple planned kinetic effects ultimately generates second order effects within the larger organizational units. It is even possible that a single, timely, kinetic effect can directly cause third order effects. But for that to occur, the larger system would have to be in a critical and highly sensitive state. Complexity scientists refer to such a state as self-organized criticality. Consider the assassination of Archduke Ferdinand in 1914 and the introduction of the Apple iPod in 2001 as examples of effects-based thinking and complexity. An anarchist assassinated Archduke Ferdinand in August of 1914 which precipitated the First World War - true in a way, but that's a misunderstanding of the complex system that existed in Europe nearly a hundred years ago. A complex array of treaties and political relationships existed in a critical state. War was virtually inevitable - it only needed a small push. Another good example of complex relationships and adaptive leadership that helps us understand effects-based thinking is the consideration of the music industry. The music industry existed in a similar critical state in 2000 with technology and downloadable music threatening intellectual property rights and profits of major entertainment corporations. Into that system stepped Apple, who launched one of the most successful products in history. The iPod's success was due in part to the criticality of the system and Apple's adaptive leadership and decision to seize the opportunity inherent in that instability. For businesses, sensing such critical states is the essence of recognizing opportunity - an opportunity that is clearer to those possessing effects-based thinking and adaptive leadership.

All activity in a social organization takes place through individual actions or it is carried out by processes designed and implemented through individual actions. People originate action and therefore create effects. Take a moment and think about what it means. A corporation is a legal entity much like a person. However, regardless of the legal status of a corporation, it does not think and act as an individual - a corporation does not have the anima for effects-based thinking or the capability for developing an adaptive leadership strategy. It takes no action except through the actions of individuals. That individual may be the owner, the CEO, or the chairman of the board, but nothing actually occurs, there are no impacts or kinetic effects except through the actions of individuals. A company does not purchase raw materials. A purchasing agent purchases those raw materials either through their own decision-making process or via an inter-organizational process. A company does not merge with another except through the legal transaction committed by an officer so empowered to execute that transaction. The individual person and his / her capacity for effects-based thinking, adaptive leadership, and physical action is where the rubber meets the road in social systems.

For example, if the vision or goal of a retail chain is to capture the largest segment of its market, then it is not the regional manager that sells the product. It's not the district manager that builds a new store. It's not the store general manager that stocks the shelves. It's the sales rep that sells the camera to the customer. It's the contractor that pours the concrete. It's the store associate that stocks the green beans. The third order effects desired by the organization upon the larger market system must be translated in a cascading fashion from the very top of the organization to simple actionable tasks at the individual level. It does this through clear, adaptive leadership in the context of effects-based thinking.

Summary

We utilize the word "thinking" in effects-based thinking for one very important reason. Although the concept finds its roots in military operations, and is known as 'effects-based operations' in military circles, the application is much more broad, and perhaps more important in non-military settings. We call it 'effects-based thinking' because of the absolute necessity for human thought processes and adaptive leadership to cut through the muddy waters of complexity. Effects-based thinking, at every level in an organization from the CEO to the 'Strategic Corporal' must ultimately rely on well-informed judgment to guide right action. Technology can only provide more information. It cannot provide meaning and it can't decide anything.

Humans are made to think and decide - to choose. But, how we do that, well or poorly, is dependent on many factors. Those factors vary from one individual case to another. And, when combined in group planning, those individual factors multiply and create greater challenges to orchestrating planning and decision making as a group - and are further magnified when we must coordinate such planning and decision making at the organizational level. How do we comprehend all the complexity around us and within our organization in order to plan for and foster adaptive leadership? How do we coordinate all that activity? How do we know our plans are effective? How do we manage all this in an ever-changing environment? Effects-based thinking and adaptive leadership give us the first cognitive tool to deal with these daunting challenges.

James D. Murphy,
Founder and CEO of Afterburner, Inc.

Effects-Based Thinking: Part II

James D. Murphy — Wed, 27 Jul 2011 16:36:00 GMT

In 'Effects-Based Thinking - Part I', the definition of effects-based thinking, or EBT, was established as an approach to strategic planning which contributes to long-lasting organizational impacts. Expanding on this concept, let's look at what the differences between strategic planning with EBT and simply tracking progress with metrics are.

Many organizations utilize scoreboards or dashboards to track progress toward goals. Such methods have values that can be measured in a continuous manner to track performance. But such tools are just that - measures of performance toward discreet objectives, but not necessarily a component of effects-based thinking. These objectives do not always have a clear connection to the organization's overarching goals or vision that one gets with EBT. For example, making a certain amount of revenue or delivering a particular earnings per share by the end of the year are great measurements. How are we going to know whether the actions we are taking today and tomorrow are having the right effects upon those measurements? How can we utilize effects-based thinking to know that we aren't just getting lucky? Furthermore, how do we even know that those measurements are the right measurements? And how do we know that the sum of the individual actions taken to affect these measurements, which often form the basis of incentive systems, are not interfering with each other or ultimately damaging the organization? This is where effects-based thinking or EBT comes into play.

Every organization is a complex system that is typically composed of smaller complex systems that are interdependent. Interdependencies between complex systems are unpredictable and can create unintended effects or consequences. So, the lesson to learn is that scoreboards and dashboards alone are not necessarily good indicators of progress toward achieving organizational goals.

So, how do we manage organizations in uncertainty? We do it by first developing an understanding of effects-based thinking (EBT) throughout an organization. Do the people at the lowest levels of the organization have an understanding of the organization's overarching goals in order to make the right decisions? Do they have the freedom to exercise judgment? Do they have access to the information they need to make those judgments? What about the middle managers - do they have the necessary understanding of goals and freedom of action to use effects-based thinking in the organization's best interest? Furthermore, whether they make the right or the wrong decision, are they learning from it and transferring that learning horizontally and vertically throughout your organization with EBT? Lastly, are the organization's senior leaders learning from what the junior leaders are learning in order to adjust the organization's course and strategic direction? To do all these things and remain agile in order to adapt to the precarious changes in complex environments requires effects-based thinking.

Everything exists within a system and every component of the system has the ability to affect everything else, as these components are interdependent. Central to EBT is this notion that effects transmit through systems in three orders: kinetic, second order, and third order.

Impacts and Kinetic Effects in EBT

Think about actions in EBT as "impacts." Impacts are the actions taken or an event that has occurred that causes the rippling effects that cascade throughout the larger system. These impacts are "kinetic" effects. Kinetic effects in effects-based thinking are measureable and immediate. Typically, then, kinetic effects are localized. The effect remains within or close to the originating system or transmits merely to the neighboring systems. Kinetic effects have a tendency to be a small step toward some larger objective.

Second Order Effects in EBT

Second order effects connect the very actionable, controllable, and immediately measurable kinetic effects to the long-term organizational goals that affect the much larger market or global system. Within effects-based thinking, second order effects are those that have a significant impact on the primary systems that comprise the overall system. That is, they correspond to an organization's individual strategic objectives. Because second order effects have a much longer range than kinetic effects in EBT, they typically only manifest themselves over a period of months or even years, and present a challenge to measurement.

At the level of second order effects, complexity sets in and it isn't always clear what might be affecting the success or failure of strategic objectives. Measurements may or may not be relevant to those objectives so paramount in effects-based thinking. So, the effects that we want at the second order of EBT must first be described as desired effects in a simple, clear manner before we attach measurements to them. We must also always hold the desired effect as primary over the measurements and continually ask ourselves whether the measurements are indeed a reflection of progress toward the desired effect. If we can't make that connection, then what is the compelling reason to keep doing what we are doing? Are our actions in effects-based thinking achieving our desired effect?

So, EBT's second order effects are the culmination of a few or many kinetic effects. They most likely align with an organization's strategic goals. Therefore, scoreboards and dashboards of a few carefully selected metrics can be excellent tools for assessing success. But there is another, higher order of effects that can't be ignored - third order effects.

Third Order Effects in EBT

In EBT, third order effects describe an organization's future picture. A future picture is similar to the popular notion of a company's vision. But specific to effects-based thinking, a future picture is a high-resolution description of some future state of the organization. It is the set of long-range goals that the strategy seeks to attain. When we speak of 'ripple effects' we are often thinking in terms of third order effects. The set of effects, expected and unexpected, that ultimately arise as a function of activity over a long period of time - on the order of several years - is the domain of third order effects. The future picture is the set of effects we want to bring into existence with EBT. Other third order effects, whether created by entities outside the organization or by the unforeseeable consequences of actions taken within the organization, are what we must guard against.

These three levels of effects in effects-based thinking - kinetic, second order, and third order - provide a structure for thinking in terms of planning, executing, and assessing an organization's activity within complex environments. Effects-based thinking helps guide organizations through such complexity and adapt to its constant changes and challenges with greater caution. But, perhaps even more importantly, EBT provides everyone in that organization with a simple structure to guide and align their actions towards long-range success.

When we bear in mind our ultimate goals when planning and executing toward immediate or short-range results, we utilize effects-based thinking to align our actions more effectively toward those ultimate goals. With EBT, we're also able to better construct, align, and adapt our measurements to ensure we aren't measuring the wrong things or, worse, driving the wrong behaviors.

James D. Murphy
CEO of Afterburner, Inc.

Upside down Procedures and Processes

Mike Cunningham — Wed, 27 Jul 2011 12:00:00 GMT

Are we looking at it all wrong?

Do you ever get the feeling that you are seeing something very different than the other guy? I don’t just mean the glass half full/empty outlook on life, but fundamentally are we looking at things the wrong way?

I sometimes get that feeling when dealing with projects that involve processes, and all my projects are about processes! Take the following scenario, the stakeholder or client has a problem; they know they need to improve some processes in the organization, but are not sure exactly where to begin.

As the designated Agent of Change we provide them with guidance to determine goals and objectives to scope out the next steps. For example:

· Need to document existing processes accurately

· Train existing staff how to follow these processes

· Be able to standardize the process for quality and efficiency

Before I continue, let’s go back in time …

Back to the Future

In 1770, James Watt pioneered the use of drawn-to-scale engineering plans for the manufacture and installation of industrial products1[. These were used to assist in the successful deployment of his products; steam engines for factories driving the industrial revolution. Over time these plans evolved from crude drawings to assist an experienced engineer to more detailed plans that were created by a junior draftsman. This was the forerunner of today’s Computer Aided Design ]2[ world. Detailed, precise instructions permitted products to be manufactured without the need for hugely skilled labor, and a bridge was created between design and production engineering.

In many ways the Subject Matter Expert/Project Manager takes the same role today as those early engineers. Understanding in detail what needs to be done, and translating these complex processes by way of underlying skills, experience and well established methodologies.

The time may be right to go back and look at a different way of doing things; one that may change industry again.

Looking at the pie instead of the ingredients?

When an expert looks at a problem they often want to show off their skills. Look at me I am smart, indispensible, letters after my name, better than you … got the idea. Now all project managers are not this way, but there is a tendency to want to show off our skills versus others in the project.

One way this happens is we often/always start looking at process FIRST. Because we are good at seeing the big picture, grasping the complex, overanalyzing the simple; so we habitually start with the complete process.

As a result we are often way ahead of where the client/stakeholder is in the project. Being ahead a few steps is probably OK; being so far ahead they can’t see your dust creates distance, misunderstanding and communication problems. They may not feel that you are on the same wavelength, and we all know where that leads. We don’t want to go there.

Start with the tasks, not the process.

Recently, I have been examining this problem with some precision. I know Business Process Management has the word process in the middle, and is therefore important. However, every process is full of tasks, activities and decisions. The client/stakeholder may not yet see how all these tasks are intertwined to make up their own work processes, but they understand the basis of all processes are tasks. So why don’t we start by capturing the tasks first? Good idea!

A task centric approach has several advantages over process first. These include:

1. It’s easier to get the client/stakeholder to capture precise information about roles, ownership, guidelines, resources, timeframes, frequency etc. on a task basis

2. Once you have all the important tasks documented it’s easier to then order them for the “as is” or “current state” of operations

3. Get everyone on the same page for the process documentation project

4. Builds a base of foundation data for the project

Once this task library has been created, we can return to the process view. However now we have the details we need to build on our “Discovery” phase of the project. If you have used Excel or a similar product to capture this information, it will be easily sorted and can be then categorized for the process capture stage of the project.

Conclusions

Just as we learn the alphabet, words, sentences, grammar before creating great prose; we need to apply the same principles to our Process Management activities. Taking logical steps to breakdown the “Discovery” process into tasks and then build the jigsaw puzzle that is the process makes sense.

Given the potential for re-use of tasks in best practice models, this approach may have much merit in Process Improvement methods.

]1[ NMSI. The Production Process. May 20, 2011. http://www.ingenious.org.uk/Read/Seeing/Drawings/Theproductionprocess/.

]2[ Wikipedia. Computer-aided Design. May 20, 2011. http://en.wikipedia.org/wiki/Computer-aided_design.

]

Strategic Planning and Effects-Based Thinking: Part 1

James D. Murphy — Fri, 22 Jul 2011 20:17:00 GMT

As the name implies, effects-based thinking (EBT) is an approach to strategic planning and decision making where the effects of specific actions are assessed, not in a narrowly defined and time-limited way, but through a perspective that is sensitive to broad-ranging and lasting impacts. Effects-based thinking is the opposite of short-sightedness or myopia.

Sadly, we have the ability to think about effects, yet we often don't. In our fast-paced personal and work lives we tend to think more about today's issues rather than tomorrow's. Strategic planning objectives get pushed back further and further to accommodate those immediate concerns. Modern organizations tend to exacerbate our naturally myopic tendencies by planning in small executive teams and passing down narrowly defined objectives and goals with little connectedness to overall goals. Ironically, narrow strategic planning sparks our natural capacity for effects-based thinking. In the wake of some failed corporate plan, the water cooler conversations buzz with effects-based criticisms like, "Didn't they realize that was going to happen?" or "I saw that coming a mile away."

To some extent we are all effects-based thinkers. If you ever said to yourself, "I'm not going to stay up to watch the rest of this game because I won't get enough sleep and I have a busy day tomorrow." Or, if you decided to enroll in graduate school to get an MBA so that you would have better career options, then you are certainly thinking about effects. In this sense, effects-based thinking is a fundamental human trait in our strategic planning processes. We envision some future or some goal, or we analyze some set of choices or actions and we think forward through a chain of cause and effect to make decisions. Thinking about effects is part of our nature as humans.

However, few individuals or organizations utilize effects-based thinking systemically. Such an organized, process-oriented approach is what we mean by effects-based thinking. We partially define effects-based thinking as strategic planning and decision-making directed to shape an organization's picture of the future. This is only a partial definition because we must additionally consider what we know about complex systems - that they are inherently unpredictable and subject to rapid, even destructive change. Furthermore, actions can produce unpredictable effects and unintended consequences within complex systems - even with a comprehensive strategic planning initiative. In complexity, the cause and effect sequence will always have some degree of ambiguity. Unfortunately, we're stuck with the fact that no person or group of people has completely reliable predictive abilities about complex systems. We also know that within complex systems, root causes of effects can be obscure. So, even with the benefit of hindsight, we may not know precisely what forces are at work to yield any given effect. Therefore, we must be ever vigilant about what is happening around us. We must also continually assess cause and effect in our internal and external systems. Effects-based thinking is about more than just strategic planning by mentally projecting through a series of causes and effects. It is also about assessing the effectiveness and accuracy of our predictive planning. To truly think in an effects-based way requires us to think cyclically rather than linearly.

To be more accurate, effects-based thinking can be defined as a continuum of strategic planning and assessing the effectiveness of actions directed to shape an organization's overall goals and objectives. In other words it's "how do we get what we want and how do we know we're making the right choices to get it". And that seems pretty simple and straightforward if it were not for this pesky problem within most organizations known as "execution".

Organizations create plans that span the course of years. They call these plans "strategies." But leaders in organizations struggle to coordinate or orchestrate the execution of these strategies and utilize effects-based thinking. One of the many reasons for this is that the strategic planning is often not well connected to the operational plans, or what military planners call "tactical plans." The strategic plan often spans a period of years while the tactical plans may only span a period of days, weeks or a month. There is a missing strategic planning tier needed to bridge that gap - one that spans the multiple-month to multiple-year gap. Without effects-based thinking, the plans we carry out on a daily basis are hard to connect to the overall strategy that spans a year or more. In that case then, how do you measure your progress in support of the strategy? And, even more importantly in this rapidly changing complex world, how do we know our strategy is still a viable one? Complex phenomena obscure our ability to determine whether our chosen course is correct. So, what do we do? Do we just keep plugging along for months or even years until it becomes painfully obvious that our strategy is ineffective or needs adjustment, and then employ effects-based thinking?

In 2010, IBM produced a report about strategic planning called Capitalizing on Complexity. This report clearly outlined the challenges of operating in a highly complex world, what it called a "global system of systems." In its conclusions, it made several recommendations, all of which agree with the fundamental assumptions inherent in Flawless Execution. But one in particular speaks directly to effects-based thinking. The report instructs the reader to: "Course correct as needed. Align a few clear metrics with objectives to identify success patterns, then regularly track results as part of a continual feedback loop. Modify actions based on what is learned (1)."

Effects-based thinking is about realizing that the strategic planning-executing continuum must be continuously revised to keep pace with change. It can only do this by continually assessing the effects of actions taken and the uncontrollable changes taking place in the market or external environment.

To understand how to implement effects-based thinking into our planning requires a deeper understanding of effects and how they propagate throughout complex systems. We also need processes to help us think more clearly in terms of effects. To that end, a subsequent series of articles will explore effects-based thinking and how it impacts strategic planning. Through that series we will explore a three-tiered model of effects-based thinking. We will also explore line-of-sight alignment, a concept that connects everyone in the organization to their immediate objectives and the long-range organizational strategic goals - all through a dedication to effects-based thinking.

Works Cited

1. Capitalizing on Complexity. IBM Corporation 2010. Pg 59.

James D. Murphy
Founder and CEO of Afterburner, Inc.

Complexity: The Execution Challenge You Don't See

James D. Murphy — Mon, 18 Apr 2011 21:00:00 GMT

When you think of the word 'complex', do you ever think about what it has to do with project execution? Ask a management consulting firm to define 'complex' and you'll get a response like "well, it's a concept that can affect your life, your family, your team and your organization." That's because consultants understand that complexity lies in every aspect of strategic planning, whether at home or in the workplace, and that complexity is a concept that needs to be clearly understood in order to anticipate and overcome execution challenges.

The Oxford English Dictionary has three separate entries for the word 'complex'. But in general use it is defined as: intricate, not easily analyzed or disentangled. We live in a highly complex world and while we have a general understanding of the complexity with which we approach execution challenges, for the most part, our human brains are not wired to comprehend the intricate concepts needed for strategic planning. But with outside management consulting, companies often see that it is easier to understand the complex architecture of cause and effect.

Simplicity vs. Complexity

From our day-to-day perspective, simple and complicated things are things we create or conceive. A knife is simple. A bicycle is relatively simple. We can look at all its parts and see how it operates. You might need to understand some basic physics to understand how a bicycle's gear shift works, but that is a relatively simple concept for humans to grasp. But when it comes to comprehending the inner workings of strategic planning and its role in execution, these become complexities that are difficult to grasp - a fact that management consulting firms are well aware of.

We know that manufacturing processes are complicated, and even bureaucratic processes are complicated. And just consider how complicated legal processes are. But we also know that none of these simple or complicated things creates anything greater than itself. The whole of an outcome realized through strategic planning is only equal to the sum of its parts. Without a rider, the bicycle is just an organized set of parts. Without litigation and judgment, legal execution and the enactment of laws are nothing more than ink on a page. Management consulting firms understand that human systems create something greater than their individual components. Consider the global economy - it appears to be just billions of individual people toiling away in some haphazard manner. But that global economy, as wildly unpredictable as it may be, is a complex system, reliant upon consistent execution achieved by strategic planning through a number of human variables.

When we were taught history in school, most of us probably saw human history as a sequence of causes and effects. But the world is not like a line of dominoes in which one topples to cause another to topple, then another and then another - instead, the real world is non-linear. By that we mean that the chain of cause and effect feeds back upon itself to perpetuate more change. When educating clients about complexity, management consulting firms understand that foreseeing the ultimate execution of such non-linear cause and effect interactions within strategic planning is either impossible or simply exceeds our human capacity to comprehend. Every cause is the sum of countless effects and every effect is the sum of countless causes. Cause and effect become indistinguishable from one another. We must relinquish our linear view of the world and embrace its complex wholeness. We must view the world as a complex interdependent system.

If it weren't for complexity, all our challenges and strategic planning problems could be reduced to manageable and highly predictable processes that we could shape to achieve the execution we desire. But complexity is an integral aspect of life itself - a concept that management consulting firms impart to help corporate clients understand how to approach complexity in the workplace.

Complexity Directly Affects Business Leaders

IBM conducted a survey of over 1,500 global CEOs and other leaders and in 2010, and produced a report entitled Capitalizing on Complexity in which the first of its four primary findings identified the following: "Today's complexity is only expected to rise, and more than half of CEOs doubt their ability to manage it (1)." Leaders often identify complexity as such an issue in execution, but businesses can leverage a management consulting firm to manage the intricacies of strategic planning to embrace and manage complexity.

Peter Senge, in his groundbreaking management book The Fifth Discipline, challenges us to see the world as a whole, to see the "subtle interconnectedness that gives living systems their unique character (2)." He challenges us to see our world, and our business execution, as part of systems and as systems themselves. The interplay of cause and effect in strategic planning is dizzying and in our limited comprehension, appears chaotic and has far-ranging consequences. Managing complexity, though difficult, is not impossible (at least in the short term) and management consulting firms teach clients how to prepare for unpredictable environments. At best, we can only anticipate change, plan for it, and respond wisely when it surprises us.

The Rate of Change is Increasing

If the science of complexity teaches us one thing, it is that our human world will always remain unpredictable. As the level of complexity continues to increase, the rate of change increases - making managing strategic planning to achieve execution more difficult. It is this speed of change that both confounds and excites organizations all over the world, and prompts companies to seek management consulting to build a forward-looking strategy. It confounds because only highly energetic and creative organizations can keep up with the pace of change. It is exhausting and worrisome. But constant and rapid change also means that there are more and more opportunities available to those ready to seize them and take action.

And yet, it's astounding how people tend to think that management consulting concepts and strategic planning are linear processes. The array of business publications available on bookshelves today demonstrates this thirst for linear execution and computable certainty. It's as if the majority of people believe that there is some mystical set of rules that, if we knew them, would guarantee success. But, there can be no single process or set of rules that can guarantee anything in complex systems. However, management consulting firms can equip companies with a set of process tools and principles that enable successful adaptation within unpredictable complex systems.

Management consulting companies teach simple holistic process to help us harness strategic planning in order to achieve execution within these modern, rapidly changing, globally-connected systems. One of the most important things to realize is that we and the organizations we form are constantly interacting with other complex systems. Complex systems are ubiquitous. And as far as decision-making and problem-solving is concerned, this simple fact tends to cause some very serious planning problems.

Conclusion

Surviving and thriving in a world increasingly dominated by the capricious effects of interacting complex systems requires rapid adaptability - a concept that management consulting firms have embraced, and teach to companies to help them achieve execution through strategic planning. We are all perpetually engaged in a fight with disruptive, unpredictable change. The organization that can most rapidly anticipate, process, and adapt to that change wins the battle of maneuvers. Call it what you will - maneuverability, adaptability, or agility - winning requires a fundamental understanding of the effects of interactions within and between complex systems in our companies and organizations to achieve success.

Works Cited

1. Capitalizing on Complexity. IBM Corporation 2010. Pg 8.

2. Peter Senge, The Fifth Discipline: The Art and Practice of the Learning Organization. 2006 pg. 69.

About the Author

As the founder and CEO of Afterburner, Inc., James D. Murphy has a unique, powerful mix of leadership skills in both the military and business worlds. After graduating from the University of Kentucky, Murphy joined the U.S. Air Force where he learned to fly the F-15, logging over 1,200 hours as an instructor pilot in the F-15 and accumulating over 3,200 hours of flight time in other high-performance jet aircraft. He has also flown missions to Central America, Asia, Central Europe and the Middle East. As Afterburner's leadership keynote speaker, Murphy has helped top business leaders transform strategy into action by showing that the concepts of the Flawless Execution(SM) model could be applied to business process improvement and engaging the proven model - "Plan. Brief. Execute. Debrief." Murphy has been regularly featured in such publications as The Wall Street Journal, BusinessWeek, and Newsweek, and has appeared on CNN, Fox News, and Bloomberg News to name a few. For more information on Afterburner, Inc., please visit www.afterburner.com.

Five New Year’s Resolutions for Requirements

Seilevel — Fri, 14 Jan 2011 21:38:00 GMT

It’s that time of year, where our thoughts turn to the holidays…the holiday parties, the shopping, the lights, visiting with family! For many organizations, the end of the year tends to be quiet on the IT front, for no organization wants to risk introducing problems into their production environment at year end.

So as I look back at this year on what was accomplished, I tend to do a mini-retrospective on my year…what went well, what did not, and what can I improve? Thus looking at those items to improve, I’ve come up with a list of New Year’s Resolutions to focus on for next year:

Use the ROM – Requirements Object Model

Understand what the business problem is trying to be solved for any project that I am working on. This can be difficult to get on any project, but essentially, every project should be attempting to solve some business problem. Usually these problems are rooted in money.

Once the business problem has been identified, the business objectives can be defined. And from there, the strategy to meet those objectives can be defined.

The benefit of understanding the business problem is then you are developing a solution that will provide a return on investment. No one wants to do a project just because, there should be a purpose and it should be valuable.

Write Clear Concise Requirements

Of course I always try to write clear, concise, testable requirements. But what seems to be clear, concise and testable to me may not be in reality. So I always consider this an area of constant improvement.

How can I ensure that I am writing clear, concise, testable requirements? Reviews are always a great idea. Get another set of eyes on what you have written. I like to get a peer to review my work before sending it off to my client, and preferably, someone who is not very familiar with my project. The less they know the better. For if they can understand the requirements, and then I feel like I have done a decent job in getting them document.

But these peer reviews do not take the place of reviews by the business. They are the ultimate authority, and definitely need to be done to ensure correctness and validity.

One final word on this topic and it may sound silly to state this, but I see many mistakes made because of it: spell check does not replace proof-reading. Spell check can definitely help you ensure that the words are spelled correctly, but it cannot help you ensure that you have the right words. I’ve seen embarrassing notes go out…the words were all spelled correctly…but one wrong word could mean big trouble!

Ensure Better Transparency

Transparency means being as clear and upfront with regards to the progress and status of your project. One way to help ensure transparency is to provide status reports.

I try to send frequent and consistent status reports help provide information on how the project is progressing to those who need to know. These reports should include information such as what was accomplished that week, what was not and why, what is planned for the next week, and any risks or issues that have arisen. This information helps me keep a running record of what has happened in the project, and can help refresh memories when people have forgotten what has been done.

They do not have to take long to create, especially if you create a template, and if you are consistent with sending them out, they become part of your routine.

Do Requirements Traceability

I try to ensure that all requirements map back to the stated business objectives. This helps ensure that no business objectives have been missed, but also helps prevent scope creep.

While we all know that traceability is a good thing to do, it is laborious and tedious to do, especially outside of a requirements management tool. As requirements are written, reviewed and edited, maintaining traceability can be very difficult. I try to wait until later in the requirements definition process can save some work; however, I have to be careful about waiting too long. If I wait too long, then I may miss a chance to add missed requirements, or to prevent scope creep.

Use Models

Finally, I need to use various models to describe requirements. There is no one model that can demonstrate a set of requirements fully and completely. A combination of several models allows the requirements team and development to see the requirements from several different perspectives. It helps us gain a full understanding of what is being requested, and helps ensure that there are few misunderstandings.

While it may be easy to say “use models”, it can be a challenge to get an organization to do so. People get comfortable with their current process, and can be reluctant to change. They may resist the introduction of anything that is perceived as more work. To get around those that are resistant, I try to constantly show how the model s adds value. I remind other business analysts and product managers ultimately, the models are not for them…they are for the business to confirm their requirements, and they are for development to get a full understanding of what is desired. We are in the business to help others clearly define what they need, and to help deliver those results.

Finally, I would like to wish all of you healthy, safe and happy holiday season!

Want more on requirements and requirements models? check out our other posts.

http://requirements.seilevel.com/blog/

Career Possibilities for Business Analysts-expanding your horizons

HSantanam — Wed, 17 Nov 2010 16:55:00 GMT

You have achieved your short term BA goals. You want to expand your horizons and see what else is out there and how you can progress in your career and gain knowledge and keep your career up-to-date as well. What are some of the possibilities out there that won't force you to re-learn something new from scratch? Some possibilities for career and knowledge expansion in areas related (or of possible interest) to Business Analysis:

Project Management: The PMP (Project Management Professional) certification from the Project Management Institute (www.pmi.org) is valued by many employers. Business Analysts, I believe, are well-suited for project management, which aims for successful completion of projects from inception to closing, while managing (juggling?) competing constraints of time, cost and scope. The PMBOK (Project Management Body of Knowledge), which is similar to BABOK, is a framework used in implementation of best project practices regardless of industry or project scope. The concepts used in PMBOK would be familiar to anyone who knows BABOK - for example, processes in the knowledge areas have inputs, tools and techniques and outputs. The PMP certification is valid for 3 years and may be renewed by obtaining training or other credits known as PDUs.

Information Systems Security: The Certified Information Systems Security Professional (CISSP) certification from the International Information Systems Security Certification Consortium Inc - "ISC2" for short (https://www.isc2.org/) - is also in demand for professionals catering to security related aspects of Information Technology - from IT systems architects to developers to Audit, Compliance and Risk managers. The CISSP Common Body of Knowledge (CBK) covers 10 domains - Information Security Governance, Security Architecture and Design, Cryptography, Physical Security, Access Controls, Applications Development Security, Legal-Regulations-Compliance and Investigations, Business Continuity and Disaster Recovery Planning, Operations Security. The aim is to instill a comprehensive overview of the various aspects of the IT environment and how they all relate to security and best practices. Like the PMP, the credentials need to be renewed every three years through training, volunteering in ISC2 programs or other related knowledge.

Some other certifications from ISC2 that may be of interest:

Certified Secure Software Lifecycle Professional (CSSLP) (https://www.isc2.org/csslp/default.aspx) : As the name implies, the certification is for those involved in the software lifecycle and is concerned with building security into the entire Software Development Life Cycle. It deals with secure software knowledge in the design, implementation/coding, testing, acceptance, deployment, operations, maintenance and disposal domains.

Systems Security Certified Practitioner (SSCP) (https://www.isc2.org/sscp/default.aspx): According to ISC2, this title is good for Network Security Engineers, Security Systems Analysts and Security Administrators. So Business Analysts who want to learn more about the security area and become experts may consider this.

The CISSP certification can also be obtained, in addition to the general CISSP described above, in specializations ("concentrations") below:

Pasted from <https://www.isc2.org/concentrations/default.aspx>

Other certifications currently in demand include:

ITIL (http://www.itil-officialsite.com/home/home.asp) - (Information Technology Infrastructure Library) which is a set of concepts and practices for Information Technology Services Management. It deals with management , delivery and support of IT services to business - which would be ideal, for say, managing a hosting area, data center, software as a service, change management and well..you get the idea.

Certified Information Systems Auditor (CISA) from ISACA (originally Information Systems Audit and Control Association, now known by its acronym only)

For Business Analysts who think they have a knack for probing IT systems and ensuring that process conform to policies and want to pursue an IT audit/Compliance career, the CISA might be a good bet.

Other certifications from ISACA in a similar vein include:

Certified Information Security Manager (CISM) - for those who design, build or manage IT security programs.
Certified in the Governance of Enterprise IT (CGEIT) - for those involved in IT governance.
Certified in Risk and Information Systems Control (CRISC) - for those involved with risk assessment/evaluation/monitoring/response etc.

Information on the above certifications can be found here: http://www.isaca.org/CERTIFICATION/Pages/default.aspx

There are many other paths to expand one's career horizons, depending on interest, time and inclination - Solutions Architects, Enterprise Architects, Database analysts and Network specialists are only a few - business analysts, due to the detailed nature of their work, are well positioned to transition or acquire new skill sets.

The emerging field of Wireless application specialists - mobile apps, application security (wireless protocols, app security design etc) is also lucrative. As mobile technology and gadgets (smart phones, tablets etc) get more mature, more business functions will add on mobile functionality.

If there are other interesting accreditations, certifications or knowledge programs that I have missed, I would love to hear about it…Thanks

HS.

Moving to Agile Documentation – why ‘Pair Inspections’ make sense

FergalMcGovern — Wed, 03 Nov 2010 11:00:00 GMT

One of the more controversial techniques fostered by some in the agile community is ‘Pair Programming’. It is a practice that originates from Extreme Programming, a specific Agile process pioneered by Kent Beck.

It is controversial, particularly for larger corporates because it seeks to adjust human behaviour patterns. In Pair Programming, developers sit side by side, sharing one machine and working in teams of two at all times on a single code base. In reality, it is one of the agile techniques that is likely least adopted and most controversial among programmers for a variety of reasons, mostly cultural and behavioural in nature. Most fundamentally, for a team to be successful at pair programming takes a lot of hard work. It’s a bit like a marriage really, personality compatibility is a key pre-requisite and just like marriages, the best work well but not all will be successful.

Pair Programming in action

The point of this post is not to get into the specific argument as it relates to agile developer activities for code, but rather to propose something that Project Managers and Business Analysts should actively consider for documentation and that is what I will call ‘Pair Inspections’ or PI.

The issues I have found with larger document sets in lager initiatives, especially larger documents such as BRDs and Detailed functional specifications and Test Plans is that they are:

generally authored by one and only one person with one vantage point
are worked on for a concentrated period of time by one person
do not combine the considerations of other relevant stakeholders
if inspections are going on, they are at a particular point in time, typically at a phase gate and are not that effective at spotting real issues. Infrequent code inspections suffer the same fate in my experience, if I reflect on my time running engineering teams

Now, I am not suggesting that we have co-authoring sessions for a single document. The nature of MS Word and the fact that many people are distributed make this in many cases impractical.

What I am suggesting however is that documents are reviewed actively & informally as part of the authoring & document production cycle. Let me suggest some simple measures that would achieve this:

Frequency: Conduct a Pair Inspection once a week. This may be ‘analysis phase’ in waterfall, or pre-sprint stage in Agile
Alternate stakeholders: Every other week try to include a stakeholder who wears a different hat, e.g. pair a BA with a Test Lead, pair a BA with a PM
Distributed Teams: For distributed BAs working in remote locations, use collaborative tools such as webex, gotomeeting or livemeeting.
Consistency: Put a solid recurring meeting in your calendar every week at the same time and take it seriously
Informality: Make pair inspections a way to gel stakeholders. Don’t impose rules but let the inspection process ‘self-organise’

The net effect is that substantially better documentation results when active & collaborative inspections and reviews occur, regardless of whether you are in a waterfall or agile environment.

Applying the above simple steps tightens document quality in very material ways.

------

Fergal McGovern, Founder VisibleThread.

See our main blog at: http://www.visiblethread.com/blog/

The single most important failure with requirements

Seilevel — Thu, 23 Sep 2010 00:59:00 GMT

A lot of our clients bring us in to fix their requirements issues. Based on the literature a lot of what you see about requirements is geared towards making sure that you write a requirement in the correct way – measurable, testable, traceable and atomic. Our experience with many Fortune 500 companies leads to a different issue being the most important issue, one that seems easy to solve, but is actually incredibly difficult to solve.

Ultimately software projects get chartered because an executive decided that it was worth spending the money. This should be related to a corporate strategy in some way, but usually is not. The breakdown and the ensuing issues almost always occur at this level.

The single most important failure with requirements occurs when executives charter a project without a measurable business outcome.

This sounds like an absurdly simple problem to solve, but I assure you it is not. For a variety of reasons, executives chartering software projects are adept at avoiding any sort of accountability for results. What makes the problem extraordinarily hard to solve is that it requires the leaders in the company, the CXOs, to demand that business results be identified from every program. Surprisingly this doesn’t happen very often.

The lack of clarity around measureable business objectives drives a lack of clarity to the entire rest of the project. This doesn’t mean that all projects will fail – often times project teams deliver a reasonable quality product that does generally the right things. These cases are when the issues are so completely obvious that it is virtually impossible for anyone to get it wrong. But more often people on the project invent many different reasons for why a project exists.

This single issue can result in a myriad of project problems. The issue manifests in many different ways including:

1) Projects go massively over budget because of scope creep

Scope creep is extremely easy to solve if you know what you are trying to achieve. Typically scope creep is introduced for areas that have nothing to do with the core purpose of the project. The ideas will always be good ideas, just not key to the measurable value of the project. On one project we worked on, the value was a $20M one time gain with a $20M yearly gain. The project cost was $2-3M. The stakeholder team (developers, project managers and business users) consistently wanted to add features that made the business users’ jobs more streamlined. The software would already increase their productivity, but not as much as they wanted. Because of a focus on the return (unrelated to productivity), we were able to keep the scope creep out of the release and deploy much sooner.

However on another project, the executives refuse to assign business objectives to the project and the business users keep asking for additional features that are “critical”. When we evaluated the return on the features, the return is literally almost zero and the cost is in the high 6 figures. This project is extraordinarily late and has no clear direction.

2) Projects are constantly short of resources because too many projects are being worked on

One organization we work with consistently charters too many projects. The money is there, but the resources simply are not. This means that many projects get started but then stall or are poorly deployed because key resources, including developers who know the ecosystem are simply overworked. We started on a project once that had a $4M yearly return. This was not bad, except that there was another project that had a $100M yearly return. We recommended to our stakeholders that they cancel our project and move the entire team over to the more valuable project. They chose not to and neither project has significantly deployed (6 months late). Under resourcing all projects by a little (or a lot) results in no projects being deployed well. A better strategy would be to identify the top projects by business objectives and resource them adequately. The I want it all strategy is doomed to fail.

3) Projects get canceled due to lack of interest

Projects often get chartered due to the charisma of a single stakeholder, but because there isn’t any business value they often eventually run out of steam. This actually is a better result than a project that keeps trying to deploy because canceling the project saves a lot of money. This could be avoided in the first place by proper portfolio management based on measurable business objectives.

4) Projects deliver but don’t get used by the users

This is a difficult one. We see this happen quite often and depending on the environment it may or may not be a problem. In one of the examples above, the users didn’t want to use the software because it wasn’t as easy to use as they would have liked. Yet the company could immediately get a lot of value from it. In this case it was worth it to deploy the software because the value was there and when it was explained to the users they were willing to take a usability hit to get the value. I feel bad for the users because they are the ones to suffer from these types of decisions. However I do believe that the organization is committed to successive releases that will improve usability and the cost of those is incorporated into the overall ROI . In cases where the business does not support the value the software simply does not get used. I have seen sales VPs tell the CEO that if their teams are forced to use a particular release of software that they can’t hit their very public revenue targets. This game of chicken can be avoided by making sure there is agreement at the executive level of the value of the software.

If your organization has a culture of accountability then you might already be doing these things. Our experience is that most companies have a lack of accountability for measurable business results when it comes to deploying software. As a lowly BA or IT product manager you aren’t going to be able to change the business objectives or corporate strategy, but in our experience you can make sure you understand them and even rewrite them for your team in a measurable way. This requires you to step up and choose to be held accountable. If you are able to do this and can achieve results, I assure you this is the best way to get on the career fast track.

Are you up to the challenge?

http://www.seilevel.com/

IT Black Ops

Seilevel — Sun, 22 Aug 2010 23:26:00 GMT

I’ve worked on at least one project now and heard of several others where a super-secret development team works in parallel to solve the same business problem as the “official” IT project team. A coworker of mine coined the term “IT Black Ops” to refer to these sorts of projects where the business, either out of frustration, arrogance, or ignorance, hires their own shadow development team to implement a competing solution, or an enhancement to an existing solution. I’ve never seen this go well. However, unless you are at an executive level, there is very little you can do to shut down the black ops team. In many cases, you won’t even realize the black ops team exists until the last minute when you are forced to integrate their spaghetti code solution with what the actual IT project team has built. Of course, this kind of surprise is to be expected, since the very nature of IT Black Ops is to operate stealthily, and for their business owners to neither confirm nor deny their very existence. However, once their presence is detected, a project and budgetary train wreck usually ensues.

I’ve done a little bit of thinking recently about why IT Black Ops projects are launched in the first place. It’s probably because of one or more of the following reasons:

1.Low confidence that IT will be able to build something that actually solves a business problem. Sometimes this low confidence is warranted.

2.No budget to build something the “right way” (i.e., gather requirements, manage the project, test it, and deploy it).

3.Business owner finds an extra million dollars in the budget and can finally implement his/her pet feature, even though it was initially shot down because there was no ROI for it.

Lack of understanding about why it takes so long to develop working software.
Even though the decision for the business to go undercover with their IT development will likely be disguised, there are a few ways you can help prevent them from wanting to do this in the first place:

1.Keep the business engaged throughout the development lifecycle. Giving the business partial ownership over the project by having them sign off on and review working prototypes is a great way to give them confidence in the system and make them feel as though the solution is a joint effort.

2.Sell them on the value of process. The ROI for good processes is difficult to calculate; however, turning a team of developers loose to write code with no requirements or process discipline is about as successful as hiring a room full of 1000 monkeys to develop your solution. Giving the business ownership of the process will help.

3.Each project should have a clear ROI. This sounds obvious, but too many projects have a vision statement akin to “you know it would be really cool if…” People also become emotionally invested in certain solutions, without taking the step back and evaluating how well the solution solves a business problem. Just watch out for pencil-whipped and contrived ROIs. Be suspicious of any feature which does not tie back to a quantifiable business objective.

4.Use comparable projects to set expectations. People who do not work in software development often find it difficult to understand how expensive and time-consuming software development can be. This can sometimes lead to the attitude of “This is simple–I can do it faster and cheaper myself”. In order to head this off, it helps to show the budget, resources, and time to execute for similar projects. It is natural to ask the question “Why is it so expensive/time-consuming/so resource-intensive?” You can use the lessons learned on other projects to help answer this question.
It never really helps to mention that the black ops team will always fail, that someone will get fired if the black ops project continues, or that it will end up being more expensive in the long run–even though these statements are almost always true. Once the black ops team is hired, you’ve already lost, so do what you can to prevent IT Black Ops projects from being launched in the first place

This blog post will self-destruct in 500 views.

By Jhulgan

Want more? Check out our other posts here.

What do you do when the client isn’t focused on the business outcome?

Seilevel — Tue, 17 Aug 2010 18:56:00 GMT

One of the values that we bring is that we can help our clients to decide what scope to cut by providing them with a framework that links quantifiable business objectives to specific features. We create an objective chain to do this and it helps to spotlight features that don’t feed into the core business purpose. Typically our stakeholders are able to cut a minimum of 10% of features and as much as 90% while achieving their objectives.

What we are finding though is that it is sometimes a challenge because the features that are good for the company are not necessarily good at making the lives of the people using the software easier or better.

We have recently run into a case (I’m changing the dollar values and the features for confidentiality reasons) where the business side of our client had identified $50 million in potential savings each year in an area of the business related to giving discounts. The issue was that the discounts were being calculated manually and there was the serious possibility that customers were claiming millions in discounts twice. The discounting system and rules are very complex with overlapping effectivity dates, products, regions and discount rules.

The business was confident in the $50 million number based on industry studies that showed that typical companies were giving away 5% more than they needed to in improperly calculated discounts. However, no one could identify specific types of problems that might be leading to double payment. We did a little research and analysis and decided that the biggest risk area was multiple overlapping discounts and so made that the focus.

There were several issues that came up. The most critical was that the users of the system and the business team while acknowledging the problem with overlapping discount agreements, were basing their decisions on the efficiency of the team. The calculating team is an offshore team with 8 people focused on this portion of the process. The company had done a study to show that full automation could reduce headcount from 8 to 2 people.

However our view was that the savings associatied with reducing headcount from 8 to 2 people was so minimal that it wasn’t worth the effort in the beginning when we were faced with such a large amount in overpayments. Instead we felt that focusing on the features that would automate detection of overlapping agreements were absolutely critical. Deploying those features as quickly as possible was paramount because of the massive revenue leak associated with the problem. Leaving a majority of the process manual would actually be ok if the system had the ability to determine when multiple discounts were being applied to the same purchase and thus eliminate the lost dollars.

It turns out that the business simply didn’t want to fund the project unless their work was decreased, even though in the overall scheme the cost savings was minimal. In the end they approved funding for a first phase that has full automation but does not actually focus on detection of the business case driving error conditions. The detection of the error conditions will come in later phases, so ultimately they will get the business value.

We see this often where at the level of individual features, the subject matter experts have mandatory features that will make their life easier but don’t necessarily contribute to the business case for the project. These features create a death by a thousand cuts situation. Our methodology can identify the “unnecessary” features, but ultimately it is up to the client to decide if the business case is really the highest priority.

Want to see other blog posts? Check us out here: http://requirements.seilevel.com/blog/

It’s So Hard to Say Goodbye: Tips for Getting Closure on Your Project

Seilevel — Thu, 12 Aug 2010 18:50:00 GMT

Sometimes projects are like villains in horror movies: they just won’t die. Even when you’ve doused them in gasoline, set them on fire, then dumped them in a river, they just keep coming back. A project’s extension beyond its natural or expected life is not good for the project as a whole (even though it might help keep you busy). Projects are expensive and each unnecessary day spent on a project is hundreds (or sometimes thousands) of dollars that could be allocated elsewhere. Here are some tips than can help you keep the project moving towards a harmonious end for both the business and IT teams:

1. Feature Alignment: Make sure that the business understands all of the features that will be delivered as part of the project. The BRD or other requirements documentation should spell out very clearly the features that will be delivered as well as those that will not. This sounds very obvious, but it is important and sometimes neglected at the beginning of projects.

2. Fix my Defects! Here’s a dirty secret about the software industry: all software has defects! Not surprised? Well, unfortunately and often understandably, resources will be asked to stay on a project until “all defects are fixed”. If you’ve agreed to such a request, get ready to be on the project for a long, long time. A better plan is to have agreement on the level of severity of which defects will be fixed before project exit–for example, all “Critical” or “Blocker” defects. There may be disagreement as to what counts as a “Critical” defect, but much ink has been spilled on this subject already.

3. Confidence is Key Regardless of how many defects are fixed, how well the project is planned, and how proud you are of your team, your users will not be prepared to see their safety net pulled from under them if they don’t feel comfortable using the system you’ve built. One way to build confidence is by building and measuring user adoption . But sometimes, it just takes a lot of hand-holding and training on how to use the system, and an explanation of the business value.

4. Focus on Business Value No system is perfect, but every system should be built to achieve a business goal. When everyone is “in the weeds” reacting and focusing on discrete, individual tasks, it’s easy to lose sight of the big picture. It’s a good idea from time to time to review the project business objectives especially when there is disagreement over which defects need to be fixed before project exit.

Do you have other tips? Let us know!

Building Credibility With Your Team

Seilevel — Wed, 28 Jul 2010 22:07:00 GMT

As consultants and product managers, it is important that we quickly build and maintain credibility with our team so that we can work productively and effectively. If you are unable to join the team dynamics, the work that we provide will be met with apathy or even outright hostility. I’ve learned a few tips to help establish credibility quickly.

Maintain your visibility – Initially, it is important to get plugged into as many face-to-face meetings and conversations as possible. By being face-to-face it gives you the availability to learn more about the project right away, gives you context, and you will quickly meet many of the people who might influence your efforts. Your team can see you demonstrating your expertise and learning about the challenges of the project. They will see you as a member of the group. If you are not able to join many meetings, just being onsite and visible will help establish your presence.

Learn about your customer and your team - Knowing the business issues and pain points of the project team will help establish your credibility. Research the business and the challenges before meeting with your team. Usually, you will have a point of contact within the organization who can share the current challenges, and possibly some of the team dynamics. It’s also important to keep an open mind when learning about a new group. Everyone has a perspective and until you can gather your own impressions, take what’s shared with you with a grain of salt.

Be Personable – It is critical to try to establish a personal relationship beyond the necessary professional one. I’ve found that if a new team member can connect with me on a personal level; it goes a long way towards smoothing out the edges professionally. Try to ask your team members about appropriate things that matter to them, like kids, interests or holiday plans. If you do ask, be sure to remember what they told you and be genuinely interested. If you do ask about a team member’s personal interests – Don’t forget the answers. Even if you have to jot them down on a notepad to remember later. It’s critical that you not ask the same personal question twice. People may give you a pass if you repeatedly ask the same question about work related topics, but if they care enough to give you an answer about something personal, you should care enough to remember it.

Be a good communicator and listener – The ability to communicate effectively and sincerely will always enhance your ability to establish credibility. It’s important to be engaging, and build professional relationships. Effective communication can quickly build a personal rapport between you and the other team members.

Never let ‘em see you sweat-

This is hard to do in practice but important. If a person is going to have faith or confidence in your ability to get the job done, then you should have faith in yourself. Issues and problems will come up from time to time, but having grace under pressure allows people to feel comfortable that you are the part of the solution and not part of the problem.

Do you have tips on how to build credibility with your team? Do you want to check out other blogs?

You can check us out here.

By Landerson

How many Business Analysts do I need on my project?

Seilevel — Tue, 27 Jul 2010 15:29:00 GMT

At the beginning of almost every project (and even sometimes midway through them) we are asked to create a requirements plan and estimate the time required on tasks and the number of BAs necessary to execute it. In a later post I’ll talk about the actual plan items, but we do have a rule of thumb for how many BAs you need on a project.

We have a standard metric we use: we suggest 1 BA can support 4 to 8 developers. Typically I suggest 1 BA to support 4 to 6 developers though, as 8 is a stretch on many projects. Of course this number is highly dependent on the context of your project, so treat it as a rule of thumb only.

As an example, right now we have 7 developers working on rebuilding existing functionality from an existing site and it’s required just over 1 BA to work on the requirements for it. And even at that, the BA is pretty stretched to get them done as fast as the dev team needs them. And in another part of the project, we have 1.5 BAs supporting about 4 developers who are doing defect testing – but they are also very intensely focused on UAT activities.

ByJBeatty

How many BA's do you need on your project? Do you have comments?

http://requirements.seilevel.com/blog/2010/07/how-many-business-analysts-do-i-need-on-my-project.html

BA World Sydney - A review

Craig Brown — Tue, 27 Jul 2010 00:31:00 GMT

I went to the Business Analyst World Conference in Melbourne on the 19th and 20th of July. Like last year it was a great event. On day 1 I spent the whole day in one room (introducing speakers.) and got to listen to three very different stories.

Matthew Coppola from Perth training outfit Paramount Training gave a talk on Understanding Strategic Planning.

It’s always useful advice to go back to basics: Where do you want to be? Do you understand your capability? Mathew’s talk gave a simple framework to drill into these two questions. (See a transcripts of the whole talk here.)

Something that struck me while listening to his talk is how odd the world is. So many of us profess to know this stuff, but when you get out into the pressure of deadlines and complicated personal relationships – how many of us stick to the agenda and define the problem sufficiently before getting into implementation mode.

The second talk I saw was by John MacLeod of IBM’s Rational team on Steps to Better Requirements Management. This was the basics of requirements management: Start with a technology neutral business requirement statement, evolve it into a solution constrained by a particular IT or system scope and finally resolve it into specific statements of functionality. And trace things from front to back to keep up with what is getting done and what isn’t.

The third talk was a case study of a project delivered in NSW police by Peter Stanford of Artefaction called Architecting change – from Here to Eternity, or Agile and Now. This talk centred around the problems of getting consensus on big decisions in large, complex and diffuse organizations. The guts of the answer seemed to be making the decisions frequent and small, and using prototypes wherever possible.

On Day 2 I filled in for Paul Culmsee who was unable to attend – and did an ‘intimate’ Q&A session for two tables of people who wanted to ask questions about implementing agile practices. Matt Hodgson and Peter Stanford also sat in answering questions. It was fun and the people there seemed to like the more interactive nature of a conversation over yet another lecture.

The rest of the session was really interesting with lots of good content and speakers. I was happy I went and recommend anyone in Australia (or NZ) to pop along to the Sydney event on the 17th and 18th of August.

(Also posted at www.BetterProjects.net)

Is Your Product Knowldege an Asset or Liability?

Seilevel — Wed, 14 Jul 2010 16:19:00 GMT

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

“In a nutshell, the more product knowledge you have, the less product management you’re doing because your product knowledge gets you sucked in to a plethora of non product management issues.”

“Furthermore, too much product knowledge leads to micro management – the kiss of death for anyone in a leadership role.”

“Detailed product knowledge = liability because you can’t see the forest from the weeds.”

“Detailed product knowledge = liability because it forces you more into ‘how’ features should work instead of ‘what’s needed and why’ from a business perspective.”

“The more you know about your product the more difficult it is to position its true value. “

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn’t truly mitigate the liabilities. Good product management is fundamentally about good product management.

It’s your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Post by MTalbot at Seilevel Inc

check out other blogs here.

BA Careers - Domain knowledge versus analysis skills

Miles Barker — Thu, 27 May 2010 12:44:00 GMT

I've been thinking a lot recently about the value of the BA, and BA recruitment - at all levels.

A common question that comes up is "Do I need to have experience in Industry X/Domain Y to work as a BA in that industry/domain?"

In a nutshell:

Is it like that now? Yes.
Should it be like that? Probably not.
Who can change it? Us - as BAs, managers and recruiters of BAs, and as candidates.

A lot of my thinking crystallised after a Thoughtworks breakfast meeting, about the challenges of modernising an infrastructure for selling train tickets (this is way more complex than you might think!) and seeing parallels with my work. Equally importantly, the CIO of the client co (David Jack of thetrainline.com) had a great track record of applying sound IT management in some very, very different industries.

Often, talking about "Industry X" is a slightly lazy shorthand for a bunch of more abstract things about challenges, approaches, and thinking.

I think some of the key determinants are the nature of a business or domain, e.g.

Is it B2C or B2B?
Is the process tightly constrained by market norms?
Does the "customer" (internal or external) directly interact with the system or business process you are working on, or with a service that is supported by it?
Are the system's users finite enough in number for a representative sample to be dealt with directly during the requirements process?
Are the users or Customers specialists themselves, or generalists/the general public?

and so on.

I know one BA who works (with great success) in the field of Adult Social Care:

B2C
Customer interacts with a service supported by his processes/systems
Customers/users can be sampled directly
Customers/users are specialists in their profession but generalists with regards to systems or process re-engineering.

So what his job is actually about is finding innovative ways (e.g. ethnography) to help professionals and their clients discover true requirements and create new processes to deliver those more effectively.

So I could tell you that "I'm a specialist in Securities Clearing and Settlement and Collateral Management". Or, I could tell you "I specialise in state-driven transactional processing, specifically in consolidating legacy processes and systems into service-oriented models that are sufficiently abstracted to support common processing regardless of product nuances or multiple B2B interface designs, in a time-constrained environment".

Now, which sounds more portable? And which tells you more fully what skills I have?

Of course, there ARE some cases where true domain expertise IS essential, typically those with some combination of highly specialised content AND time pressure AND stakeholders whose time is (genuinely) too valuable to spend "teaching" the BA. I'm reminded of pharma - the 2009 European BA Conference included a particularly memorable talk by Astra-Zeneca's Chris Marshall on the challenges of being BA in the blue-sky research space, where they are almost all ex-scientists themselves.

But most of the rest of the time, it's because things aren't documented or modelled, or aren't standardised, or aren't innovative.

I think we want to be more than just Subject Matter Experts with a BABOK veneer. Personally, I've learned the most and been most innovative when I've deliberately moved out of my comfort zone.

When we're in our comfort zone, we take a lot of what we know for granted
When we move out of our comfort zone, it's often easier to to get clarity without being bogged down in details

And we shouldn't forget, that if we just stick to the same domain and the same group of insiders, innovation will be much harder to come by. Banking sometimes feels like a merry-go-round with people coming in an implementing basically the same idea that they have at their last three employers. Which is fine if your aspirations extend no further than playing catch-up....

So what can we do about it?

1. Improve our in-house BA environment maturity, with properly modelled and documented domains, standard Use Case libraries, etc. so as to make the transition of non-specialist BAs easier.

2. As BA managers, open our eyes on recruitment based on skills and values, rather than knowledge, and phrase our job Specs accordingly

3. Build our BA teams focussed on ideas sharing and creativity

4. As BAs, revise our thinking and our CVs along the lines outlined above.

To be clear - I'm not saying that no-one in a team/project needs specialist knowledge - just that not everyone does - and that there are distinct advantages to mix and match teams and career mobility that we are currently (mostly) missing out on.

What do YOU think?

I will be leading a "BA Career Path and Qualifications" panel discussion on this and many other topics at the Business Analysis Conference Europe in London on 27-29 September 2010 - see http://www.irmuk.co.uk/ba2010/

Miles Barker

Professional Development Director of the UK Chapter of the IIBA

milesicbarker@gmail.com